Feedback tim

hace 4 años · e97238781d
--- a/content/analysis.tex
+++ b/content/analysis.tex
@@ -1,25 +1,30 @@
 %&tex
 \chapter{Analysis}
 \chapter{Design Plan}
 \label{chap:analysis}
 The previous chapter introduced how two design methods are combined to form the bases for one complete design method.
 In this chapter, a design plan is created from this combined design method.
 The goal is to have a concrete design plan that is used in the case study.
 The goal of this chapter is to define a concrete design plan that is used in the case study.
 All of the steps in the design plan must be specific such that each of these steps can be evaluated after the case study is finished.
 The first three steps of the design phase are based on the \ac{se} approach and are already described with great extend by \textcite{blanchard_systems_2014}.
 As the evaluation of \ac{se} is not in the scope of this thesis, this chapter only covers the minimal description of the design steps in \ac{se}.
 The steps that are introduced by \ridm are covered in more detail.
 The previous chapter introduced how two design methods are combined to form the basis of the design plan.

 \section{Systems Engineering}
    The goal of the preliminary design is to setup system requirements and an initial design according to the problem definition.
 The design plan consists of two parts:
 The first part is the Preliminary System Design and contains the linear set of steps from problem description to feature definition.
 The second part is the Development Cycle, which contains the features selection, variable-detail approach and rapid development cycle.

 \section{Preliminary Phase}
    The goal of the preliminary design phase is to create a set of features for the design solution.
    Although these design steps in \ac{se} play a crucial roll in the success of the development, they are, however, very exhaustive.
    A major part of this complete design process is the required documentation to ensure agreement about the design between the different stakeholders.
    Resulting in a process that can take months or even years, which is not feasible for this thesis.

    In this thesis, this design plan is only used for evaluation and has only one stakeholder, the author.
    This allows for a simple implementation of the \ac{se} approach, as it not possible to create a false start due to misunderstanding, saving valuable time.
    For each of these \ac{se} steps is explained what is involved with a full implementation, and what part of the step is used in the design plan.

    \subsection{Problem Definition}
        Before any design process can start, the "problem" has to be defined.
    The first three steps of the preliminary phase are based on the \ac{se} approach by \textcite{blanchard_systems_2014}.
    As the evaluation of \ac{se} is not in the scope of this thesis, this chapter only covers the minimal description of the design steps in \ac{se}.
    These three steps deliver requirements and an initial design. 
    The last two steps define the set of features and tests based on these deliverables.

    \subsection{Problem Description}
        Before any design process can start, the "problem" has to be described.
        In other words, why is the function of the system needed?
        This is described in a \emph{statement of the problem}.
        In this statement of the problem it is important to describe "what" has to be solved, not directly "how".
@@ -34,7 +39,7 @@ The steps that are introduced by \ridm are covered in more detail.
        As these characteristics form the foundation of the system, the requirements must be defined without any ambiguity, vagueness or complexity.
        The requirements are written according to the \ac{ears} \autocite{mavin_easy_2009}.
        \ac{ears} was chosen for this design method due to its simplicity, which fits the scope of this thesis.
        Later in the design, these requirements are divided over the subsystems.
        Later in the design, these requirements are distributed over the subsystems.
        Any issues, like ambiguity, in the requirements, propagate through these subsystems.
        This might lead to a redesign of multiple sub-systems when these requirements have to be updated.

@@ -46,71 +51,171 @@ The steps that are introduced by \ridm are covered in more detail.
        The best alternative is materialized in a design document together with the system requirements.
        This design document is used in the next phase of the design.

 \section{Rapid Iterative Design Method}
    From this point, the design plan is based on the \ridm and not anymore on the waterfall model.
    The first step is the feature definition, which prepares the required features based on the initial design.
    The features are defined by splitting the system in such a way that the results of each implemented feature are testable.
    The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature.
    During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step.

    Based on the requirements of \ridm as explained in \autoref{chap:background}, the next step is the feature selection.
    However, it became apparent that the number of tests related to a specific feature is a good metric for the selection step.
    Because, at the point that a feature is implemented, the tests are completed as well, and when the tests of the complete system pass, the system meets the specifications.
    Following the \ridm, these tests are specified at the start of the rapid development cycle.
    This makes it impossible to use the tests during the feature selections.
    Therefore, a test protocol step is added after the feature definition and before the feature selection step.

    The third step is the feature selection, where one of the features is selected. 
    This selection is based on the dependencies, tests, risk, and time requirements in the feature definitions.
    The fourth step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design and a minimal implementation.
    In the last step, the variable detail approach is used to add detail to the minimal implementation over the course of multiple iterations.
    The tests are used to determine if the added detail does not introduce any unexpected behavior.
    This cycle of adding detail and testing is repeated till the feature is fully implemented.
    From this point, the \ridm is repeated from the third step until all features are implemented.
 %\section{Rapid Iterative Design Method}
 %    From this point, the design plan is based on the \ac{ridm} and not anymore on the waterfall model.
 %    The first step is the feature definition, which prepares the required features based on the initial design.
 %    The features are defined by splitting the system in such a way that the results of each implemented feature are testable.
 %    The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature.
 %    During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step.
 %
 %    Based on the requirements of \ac{ridm} as explained in \autoref{chap:background}, the next step is the feature selection.
 %    However, it became apparent that the number of tests related to a specific feature is a good metric for the selection step.
 %    Because, at the point that a feature is implemented, the tests are completed as well, and when the tests of the complete system pass, the system meets the requirements.
 %    Following the \ac{ridm}, these tests are specified at the start of the rapid development cycle.
 %    This makes it impossible to use the tests during the feature selections.
 %    Therefore, a test protocol step is added after the feature definition and before the feature selection step.
 %
 %    The third step is the feature selection, where one of the features is selected. 
 %    This selection is based on the dependencies, tests, risk, and time requirements in the feature definitions.
 %    The fourth step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design and a minimal implementation.
 %    In the last step, the variable-detail approach is used to add detail to the minimal implementation over the course of multiple iterations.
 %    The tests are used to determine if the added detail does not introduce any unexpected behavior.
 %    This cycle of adding detail and testing is repeated till the feature is fully implemented.
 %    From this point, the \ac{ridm} is repeated from the third step until all features are implemented.

 \subsection{Feature Definition}
    \label{sec:featuredefinition}
    During the feature definition, the system is split into features as preparation for the rapid development cycle and the variable-detail approach.
    The goal of the \ridm is to get feedback of the design as early as possible by performing short implementation cycles.
    To achieve these short cycles, the features that are implemented in these cycles, are as small as possible. 
    However, the features must still be implemented and tested individually during the implementation and can thus not be split indefinitely.
    Together with the definition of the features, the requirements are divided along the features as well.
    The optimal strategy on splitting features and specifications is strongly dependent on the type of system.
    Therefore, the best engineering judgement of the developer the best tool available.

    In some cases it is not possible to define a feature that can be implemented and tested independently.
    This occurs when the feature is dependent on the implementation of other features.
    This dependency can occur in specifications, where strength of one feature dictates the maximum mass of another feature.
    Such a dependency can work both ways and can be resolved by strengthening the one feature, or reduce the weight of the other feature.
    Another type of dependency is when the implementation influences other features.
    In this case, if the implementation of one feature changes, it requires a change in the other features.
    An example of this is a robot arm, where the type of actuation strongly influences the end-effector.
    When the robot arm approaches an item horizontally, it requires a different end-effector than approaching the item vertically.

    There are two important responsibilities for the developer when the design encounters feature dependency.
    The first one is during the definition, where the developer has to decide on how to split the system and how the dependency is stacked.
    For the specification and the implementation dependency the developer must evaluate the optimal order of dependency.
    The developer must arrange the dependency of the features such that the influence on the dependent feature is as small as possible.
    In other words, if feature A can be easily adapted to the implementation of feature B, but not the other way around, the developer must go for A dependent on B.
    The second responsibility is organizing the feature requirements.
    Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected.
    This is not directly a problem, but a good administration of the requirements makes an update of these requirements easier. 
        During the feature definition step, the initial design is split into features as preparation for the rapid development cycle and the variable-detail approach.
        The \ac{ridm} does not provide a particular approach to define the features of the design.
        But, the goal is to have features that can be implemented and tested individually.
        The approach in this design plan aims to provide a more guided and structured way to split the features.
        \begin{marginfigure}
            \centering
            \includegraphics[width=21mm]{graphics/robmosys_levels.pdf}
            \caption{Hierachical structure of functions and components. Each arrow represents a many-to-many relation.}
            \label{fig:robmosys_levels}
        \end{marginfigure}
        
        The approach to define features in this design plan is based on the separation of levels principle \autocite{noauthor_robmosys_2017}.
        This principle defines different levels of abstraction.
        This starts from the top with the \emph{mission}, for example, serving coffee.
        Followed by less abstract levels such as: a \emph{task} to fill the coffee mug; a \emph{skill} to hold that mug; and a \emph{service} allows the hand to open or close.

        The different levels allow the features to be split multiple times in a structured way.
        Take the coffee serving example, to fill the coffee mug, it is not sufficient to only hold the mug.
        The system also has to pour coffee into the mug, and maybe add sugar or milk.
        This results in a hierarchical tree of functions as shown in \autoref{fig:robmosys_levels}.
        Each of the levels have a many-to-many relation with each other.

        With this approach, features are defined top-down and are implemented bottom-up.
        Thus a \emph{skill} is defined as one or more \emph{services}.
        When all the \emph{services} are implemented, they are combined into a \emph{skill}.
        The advantage of this is that the \emph{skill} defines a milestone to combine the relevant \emph{services}.
        Or looking at the example: the system must at least be able to grab, stir, and pour before it can fill a mug with coffee, milk and sugar.

        Another advantages is that multiple \emph{skills} can have a \emph{service} in common.
        This would be the case if our system also needs to serve tea. The system can already hold a mug and only needs the ability to add a teabag.
        Even though there is no exact level of abstraction required for each of the features, it does create a structure for the developer.
        In the end, the developer must rely on its engineering judgement to chose the optimal division between features.

        The bottom level of the hierarchy is a special case as it describes hardware instead of functions.
        The components are used to execute the functionality of the system with.
        For example, having a mobile robot arm near a coffee machine does meet the hardware requirements, it does not have any functionality if that is not yet implemented.
        This also creates a clear division for the developer as the functions cannot be mixed with the hardware.

 %        
 %
 %
 %        
 %
 %        
 %        
 %
 %        
 %    
 %
 %        As explained in the previous chapter, the goal of the \ac{ridm} is to get feedback on the design as early as possible. 
 %        To achieve this, the design is split into features, and each feature is implemented and tested sequentially.
 %        Resulting in smaller development cycles that are tested individually.
 %        If a feature fails its test it occurs directly after its implementation, instead of when the full system is implemented.
 %        The goal of this step is to apportion the system into features.
 %        Each feature must be small but independent, meaning that the feature can still be individually implemented and tested.
 %
 %        In some cases it is not possible to define a feature that can be implemented and tested independently.
 %        This occurs when the feature is dependent on the implementation of other features.
 %        This dependency can occur in requirements where, for example, strength of one feature limits the mass of another feature.
 %        Such a dependency can work both ways and can be resolved by strengthening one feature, or reduce the mass of the other feature.
 %        Another type of dependency is when the implementation influences other features.
 %        In this case, if the implementation of one feature changes, it requires a change in the other features.
 %        An example of this is a robot arm, where the type of actuation strongly influences the end-effector.
 %        When the robot arm approaches an item horizontally, it requires a different end-effector than approaching the item vertically.
 %
 %    \subsubsection{Feature Hierarchy}
 %        
 %
 %        
 %
 %
 %        %%%%%%%% ->
 %        There are two important responsibilities for the developer when the design encounters feature dependency.
 %        The first one is that the developer must determine where to split the system.
 %
 %        In case of a dependency, the developer must evaluate the optimal order of implementation.
 %        The developer must arrange the dependency of the features such that the influence on the dependent feature is as small as possible.
 %        In other words, if feature A can be easily adapted to the implementation of feature B, but not the other way around, the developer must go for A dependent on B.
 %        The second responsibility is organizing the feature requirements.
 %        Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected.
 %        This is not directly a problem, but a good administration of the requirements makes an update of these requirements easier. 
 %
 %        
 %        
 %
 %
 %
 %
 %    To achieve these short cycles, the features that are implemented in these cycles, are as small as possible. 
 %    However, the features must still be implemented and tested individually during the implementation and can thus not be split indefinitely.
 %    Together with the definition of the features, the requirements are divided along the features as well.
 %    The optimal strategy on splitting features and requirements is strongly dependent on the type of system.
 %    Therefore, the best engineering judgement of the developer the best tool available.
 %
 %    In some cases it is not possible to define a feature that can be implemented and tested independently.
 %    This occurs when the feature is dependent on the implementation of other features.
 %    This dependency can occur in requirements, where strength of one feature dictates the maximum mass of another feature.
 %    Such a dependency can work both ways and can be resolved by strengthening the one feature, or reduce the weight of the other feature.
 %    Another type of dependency is when the implementation influences other features.
 %    In this case, if the implementation of one feature changes, it requires a change in the other features.
 %    An example of this is a robot arm, where the type of actuation strongly influences the end-effector.
 %    When the robot arm approaches an item horizontally, it requires a different end-effector than approaching the item vertically.
 %
 %    There are two important responsibilities for the developer when the design encounters feature dependency.
 %    The first one is during the definition, where the developer has to decide on how to split the system and how the dependency is stacked.
 %    For the requirement and the implementation dependency the developer must evaluate the optimal order of dependency.
 %    The developer must arrange the dependency of the features such that the influence on the dependent feature is as small as possible.
 %    In other words, if feature A can be easily adapted to the implementation of feature B, but not the other way around, the developer must go for A dependent on B.
 %    The second responsibility is organizing the feature requirements.
 %    Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected.
 %    This is not directly a problem, but a good administration of the requirements makes an update of these requirements easier. 

 \subsection{Test protocol}
    \label{sec:systemtesting}
    During the rapid development cycle and the variable detail approach, the system is tested constantly.
    During the rapid development cycle and the variable-detail approach, the system is tested constantly.
    This is to make sure that the design still performs as expected.
    The tests are based on the specifications.
    Each specification must be covered with at least one test.
    The tests are based on the requirements.
    Each requirements must be covered with at least one test.
    The tests consist of a description which specifies how to perform the test and what the result of the test must of must not be.
    Together with the description, there is a list of required features to perform the test and a list of specifications that are met if the test passes.
    Together with the description, there is a list of required features to perform the test and a list of requirements that are met if the test passes.

 \section{Development Cycle}
    The development cycle consists of three steps, which are repeated for each individual feature.
    These three steps form the core of the \ac{ridm}.
    This starts with selecting the feature that is to be implemented, which then is implemented with the rapid development and variable-detail approach.

 \subsection{Feature Selection}
    \label{sec:feature_selection}
    The rapid development cycle does not specify which feature is implemented first, even though the order of implementation does change the feasibility of the complete development.
    The goal of this section is to improve the features selection criteria of the \ac{ridm}
    The \ac{ridm} states that critical features, those with a high \emph{\ac{cof}}, must be implemented first.
    If a critical feature fails, it is at the start of the design process, thereby invalidating only a portion of the design process.
    Features that are (time) expensive to implement, must be implemented as late as possible.
    These expensive features have a high \emph{Cost of Change} and placing them at the end of the development avoids making changes to the features.
    
    The \emph{\acl{cof}} and \emph{Cost of Change} are a good starting point for selection criteria.
    However, this creates an interesting situation for features with both a high change of failure and a high cost of change.
    The rest of this section provides a structured approach for feature selection.
    
    An example that shows the importance of the order of features is the development of a car.
    To have a critical damped suspension in a car, the weight distribution of the car must be known.
    If the suspension of the car is designed before all the features that determine the weight distribution, it is likely that the suspension design is not up to specifications.
    If the suspension of the car is designed before all the features that determine the weight distribution, it is likely that the suspension design is not up to requirements.
    Resulting in a redesign of the suspension feature and thus increasing the overall development cost.
    This example is caused by the dependency between different features.
    \begin{marginfigure}
@@ -119,60 +224,68 @@ The steps that are introduced by \ridm are covered in more detail.
        \caption{Dependency graph for features.}
        \label{fig:feature_dependency}
    \end{marginfigure}
    \begin{table}[]
    \caption{Comparison of features with their corresponding risk and time. 
        The last column is the risk value divided by the number of days.}
    \begin{table*}[]
        \caption{Comparison of features with their corresponding \ac{cof} and time. 
        The last column is the \ac{cof} value divided by the number of days.}
    \label{tab:feature_selection}
    \begin{tabular}{l|r|r|r|r|r|}
    \cline{2-6}
                                  & \multicolumn{1}{l|}{Dependees} & \multicolumn{1}{l|}{Tests} & \multicolumn{1}{l|}{Risk} & \multicolumn{1}{l|}{Time} & \multicolumn{1}{l|}{Risk per time} \\ \hline
    \multicolumn{1}{|l|}{Feat. A} & 2 (2, 3)                       & 2                          & 15 \%                     & 3  days                   & 5                                  \\ \hline
                          & \multicolumn{1}{l|}{Dependees} & \multicolumn{1}{l|}{Tests} & \multicolumn{1}{p{0.13\paperwidth}|}{\acl{cof} (\acs{cof})} & \multicolumn{1}{l|}{Time} & \multicolumn{1}{p{0.13\paperwidth}|}{Change of Failure over time} \\ \hline
    \multicolumn{1}{|l|}{Feat. A} & 2 (B, C)                       & 2                          & 15 \%                     & 3  days                   & 5                                  \\ \hline
    \multicolumn{1}{|l|}{Feat. B} & 0                              & 3                          & 40 \%                     & 5  days                   & 8                                  \\ \hline
    \multicolumn{1}{|l|}{Feat. C} & 1 (5)                          & 5                          & 25 \%                     & 2  days                   & 12.5                               \\ \hline
    \multicolumn{1}{|l|}{Feat. C} & 1 (E)                          & 5                          & 25 \%                     & 2  days                   & 12.5                               \\ \hline
    \multicolumn{1}{|l|}{Feat. D} & 0                              & 4                          & 15 \%                     & 1  day                    & 15                                 \\ \hline
    \multicolumn{1}{|l|}{Feat. E} & 0                              & 4                          & 45 \%                     & 6  days                   & 7.5                                \\ \hline
    \end{tabular}
    \end{table}
    \end{table*}

    To determine the order of implementation of features, a dependency graph and a comparison table is made.
    The dependency graph and the comparison table for a theoretic system is shown in \autoref{fig:feature_dependency} and \autoref{tab:feature_selection} respectively.
    The comparison table has dependees column, that describes the number of features that are depending on that specific feature, and are derived from the dependency graph.
    In general the dependency of the features is inherited from the hierarchical structure that is made in the feature definition step.

    The comparison table has a dependees column, that describes the number of features that are depending on that specific feature, and are derived from the dependency graph.
    The tests column describes the number of tests that are covered by implementing this feature.
    These tests are defined during the initial design and the feature definition, the number represents the amount of tests that pass after implementation of the feature.
    The risk per time score for third rule is calculated by dividing the risk score with the time score.
    The goal of this score is to eliminate as much risk as possible in the least amount of time.
    It seems logic to always implement the highest risk feature first, but it is possible to finish multiple features with a lower risk in the same time period.
    This is visible in \autoref{tab:feature_selection}: In a time span of 6 days it is possible to implement feature E or features A, C, and D.
    The risk that is cleared by E is 45 \% which is significantly less than the combined 65 \% of A, C and D.
    Due to the limited scope of this thesis, it is not possible to give a good metric for determining risk and time.

    The \ac{cof} per time score is calculated by dividing the \ac{cof} score with the time score.
    The \ac{cof} score indicates the likeliness of unforeseen difficulties during the implementation of the feature.
    The time score is an estimation about the required time for implementation.
    This time score is strongly connected with the \emph{Cost of change}, but for readability I chose to refer to time instead.
    Due to the limited scope of this thesis, it is not possible to give a good metric for determining \ac{cof} and time.
    Nevertheless, it is strongly advised that the developer defines some metric that fits his project best.

    With a completed table, the order of implementation of features is determined by the following rules:
    It seems logic to always implement the feature with the highest \ac{cof}, but it is possible that the combined \ac{cof} of multiple features is higher for the similar time investment.
    This is visible in \autoref{tab:feature_selection}: In a time span of 6 days it is possible to implement feature E or features A, C, and D.
    The \ac{cof} for E is 45 \% which is significantly less than the combined 65 \%\footnote{This is not a valid approach to calculate the combined chance, but suffices for the goal of this example.} of A, C and D.

    With a completed comparison table, the order of implementation for the features is determined by the following rules:
    \begin{enumerate}
        \item Features that are dependencies of others must be implemented first.
        \item Features that complete more system test than other features when implemented have priority.
        \item Features with the higher \emph{risk per time} score than other features have priority.
        \item Features with the higher \emph{\ac{cof} per time} score than other features have priority.
    \end{enumerate}
    The rules are applied in order, if one rule reduces the set to a single feature to implement the rest of the rules are skipped.
    The rules are applied in order. 
    If one rule reduces the set to a single feature, the rest of the rules are skipped.
    The third rule is a sorting rule, and the feature that fits best is implemented.
    In case of a draw or in special cases the developer decides what feature to implement next.

    Looking at an example of 5 features:
    As seen in \autoref{fig:feature_dependency}, Features B and C are dependent on feature A.
    Feature D does not have any dependency connections, and feature E is dependent on C.
    As shown in \autoref{fig:feature_dependency}, features B and C depend on feature A;
    feature D does not have any dependency connections;
    and feature E is dependent on C.
    Together with the information in \autoref{tab:feature_selection}, the order of implementation is:
    \begin{description}
        \item[Feature A:] has two features that are dependent on this feature, more than any other.
        \item[Feature C:] has one feature that is dependent on this feature, most dependencies after A is implemented.
        \item[Feature D:] has the same number of tests as E, but D has a significant higher risk per time score than E
        \item[Feature C:] has one feature that is dependent on this feature, most dependees after A is implemented.
        \item[Feature D:] has the same number of tests as E, but D has a significant higher \ac{cof} per time score than E
        \item[Feature E:] has the most number of tests.
        \item[Feature B:] only one left to be implemented.
    \end{description}
    Note that this example assumes that nothing changes.
    In case of a feature not being feasible during the implementation, the design has to be reviewed.
    This also means that the dependency graph and comparison table change, resulting in a different order of implementation.
    This also means that the dependency graph and comparison table change, possibly resulting in a different order of implementation.

 \subsection{Rapid Development Cycle}
 \subsection{Rapid Development}
 Each iteration of this rapid development cycle implements one complete feature.
 The feature that is implemented is selected in the prior feature selection step.
 The goal of this step is to lay the foundation for the development of the feature.
@@ -181,7 +294,7 @@ The set of detail elements is a collection of design aspects that are added to i
 These detail elements can represent behavior, parasitic elements, or components.
 How these detail elements are implemented and what the basic model consists of is based on the initial design of the selected feature.

 The initial design of the feature is similar to the system wide approach in \autoref{sec:se_initial_design}.
 The initial design of the feature is similar to the system-wide approach in \autoref{sec:se_initial_design}.
 It consists of a design space exploration, but with more detail, which is possible as the feature is significantly smaller than the complete system.
 From the design space exploration, the developer selects the optimal design choice for the current feature.
 For this design choice, a design document is made that illustrates the rough shape and dynamics of the implementation.
@@ -193,60 +306,61 @@ In general, the basic elements should only represent dominant and essential beha
 A good starting point for the dominant behavior is to identify the interesting energy states of the system.
 The energy states of interest can include the energy states that are dominant, but also the states that are chosen by the developer.
 These last states could represent the output states or status that have to be measured.
 In the end, the developer decides if states are required and implement them in the basic model.
 All the elements that are part of the initial design but are not part of the basic model are the detail elements.
 In the end, the developer decides which states are required and implements them in the basic model.
 All the elements that are part of the initial design but are not part of the basic model are classified as the detail elements.

 Lets take a motorized double inverted pendulum for example, which consists of two arms with motorized joints.
 Both pendulum arms are dominant energy states.
 The electrical motors have also internal states, but store significantly less energy than the pendulum arms.
 An basic model would in this case only consists of the arms, possibly even without any dynamic behavior.
 The dynamic behavior, motor characteristics, resistance, or gravitational force are examples of detail elements that can be added to increase the detail.
 The dynamic behavior, motor characteristics, resistance, or gravitational force are examples of detail elements to be added to increase the detail.

 \subsection{Variable Detail Approach}
 With the variable detail approach the basic model is developed into a refined model of the feature.
 This is done by implementing the detail elements over the course of multiple iterations.
 To determine the order of implementation of these elements the approach for the order of features from \autoref{sec:feature_selection}.
 \subsection{Variable-Detail Approach}
 With the variable-detail approach the basic model is developed into a refined model of the feature.
 This is done by adding the detail elements over the course of multiple iterations.
 Each iteration produces a new model with more detail than the previous.
 The newly added detail is evaluated by performing the tests that were defined during the rapid development cycle.
 \begin{figure}
    \centering
    \includegraphics[width=8.5cm]{graphics/test_flow_graph.pdf}
    \caption{Decision flowchart to follow for failed tests on each detail level.}
    \caption{Decision flowchart to follow for failed tests on each detail level.
    Decision tree starts at the top left rectangle.
    Depending on the questions, the next step of action is to continue with the design or review the design.}
    \label{fig:test_flow_graph}
 \end{figure}
 Not all tests are expected to succeed from the start, as not all details are implemented.
 For example, if the internal resistance of a electric motor is not yet implemented in the model, the motor can draw an unlimited current, and this would exceed the current draw specifications of the motor.
 The decision flowchart in \autoref{fig:test_flow_graph} in determines whether the design must be reviewed or can continue on a failed test.
 For example, if the internal resistance of a electric motor is not yet implemented in the model, the motor can draw unlimited current, and this would exceed the maximum current draw of the system.
 The decision flowchart in \autoref{fig:test_flow_graph} determines whether the design must be reviewed or can continue on a failed test.
 The decisions are made with the following questions:
 \begin{itemize}
    \item Passed Before? The current test of the current design failed, but was there a previous detail level where it passed?
    \item Expected to fail? Does the test fail as a direct result from the added detail and was that intentional?
    \item Expected to pass? Should the added detail to the model result in a pass of the test?
    \item Will pass in future? Is there an element that will be implemented that results in a pass of the test?
 \end{itemize}
 \begin{description}
    \item[Passed Before?] The current test of the current design failed, but was there a previous detail level where it passed?
    \item[Expected to fail?] Does the test fail as a direct result from the added detail and was that intentional?
    \item[Expected to pass?] Should the added detail to the model result in a pass of the test?
    \item[Will pass in future?] Is there an element to be implemented that results in a pass of the test?
 \end{description}
 In the case that the implementation of a detail element fails multiple times, the developer has to investigate if implementing the feature is still feasible.
 This could result in a redesign of the feature or system.
 When and how this decision has to be made differs per situation and is outside the scope of this thesis.
 The developer must evaluate if there are feasible alternatives left for this element, feature or system, and apply these alternative if possible.
 The developer must evaluate if there are feasible alternatives left for this element, feature or system, and apply these alternatives if possible.

 When all detail elements are implemented and the basic model has evolved into a refined model of the feature, the design cycle moves back to the feature selection.
 When all detail elements are implemented; all tests pass; and the basic model has evolved into a refined model of the feature, the design cycle moves back to the feature selection.
 In the case that this is the last feature to implement, this concludes the development.

 \section{Summary of Design Plan}
 \begin{marginfigure}
    \centering
    \includegraphics[width=6cm]{graphics/design_flow_analysis.pdf}
    \caption{Combined design plan, based on the \ridm and the Waterfall model.}
    \caption{Combined design plan, based on the \ac{se} and \ac{ridm} approach.}
    \label{fig:design_plan_analysis}
 \end{marginfigure}
 The waterfall model from \ac{se} and the \ridm \autocite{broenink_rapid_2019} are combined to create the design plan as shown in \autoref{fig:design_plan_analysis}.
 The first five steps of the design process form the preparation phase: problem description, specifications, initial design, feature definition, and test protocol.
 The initial design step creates a holistic design based on the prior problem description and specifications step.
 The steps from \ac{se} and the \ac{ridm} are combined to create the design plan as shown in \autoref{fig:design_plan_analysis}.
 The first five steps of the design process form the preparation phase: problem description, requirements, initial design, feature definition, and test protocol.
 The initial design step creates a holistic design based on the prior problem description and requirements step.
 The last step of the preparation is the feature definition, where the initial design is split into different features.
 The resulting initial design and its features together form the design proposal for the development steps.
 The last step of the preparation phase is the test protocol step, where the tests are defined to monitor the design process and validate that the system meets the specifications.
 The development cycle consists of the feature selection, rapid development, and variable detail steps.
 These three steps are applied to each feature in the initial design individually.
 The last step of the preparation phase is the test protocol step, where the tests are defined to monitor the design process and validate that the system meets the requirements.
 The development cycle consists of the feature selection, rapid development, and variable-detail steps.
 These three steps are applied to each feature in the system individually.

 With each iteration of the development cycle a new feature is added to the complete system.
 All the tests of the individual features are performed in the complete system as well.
@@ -254,5 +368,5 @@ This ensures that the one feature does not break a another feature.
 The design is finished when all the features are implemented, tested and combined.

 In the optimal situation the preparation phase is only performed once at the start of the design, and the development cycle is performed for each feature.
 However, if features prove to be infeasible, some steps have to be revised.
 However, if features prove to be infeasible, some steps have to be revisited.

--- a/content/appendix_test_cases.tex
+++ b/content/appendix_test_cases.tex
@@ -16,7 +16,7 @@
        \tcbline
        \begin{description}
            \item[Features:] Cable Bot
            \item[Specifications:] 1, 2, 6, 11, (12)
            \item[Requirements:] 1, 2, 6, 11, (12)
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item The Cable bot moved along the edge of the text area.
@@ -33,7 +33,7 @@
        \tcbline
        \begin{description}
            \item[Features:] Cable Bot
            \item[Specifications:] 7, 9, (12), 14, 15, 16
            \item[Requirements:] 7, 9, (12), 14, 15, 16
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item At the start and end of the test, the Cable bot does not move relative to the board.
@@ -52,7 +52,7 @@
        \tcbline
        \begin{description}
            \item[Features:] SCARA, End-Effector
            \item[Specifications:] 3, 4, (12), 13, 14
            \item[Requirements:] 3, 4, (12), 13, 14
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item The SCARA wrote three characters on the whiteboard within \SI{2}{\second}.
@@ -68,7 +68,7 @@
        \tcbline
        \begin{description}
            \item[Features:] SCARA, End-Effector
            \item[Specifications:] (5), (12), 17
            \item[Requirements:] (5), (12), 17
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item A tool is released from the end-effector and stored for later use.
@@ -90,7 +90,7 @@
        \tcbline
        \begin{description}
            \item[Features:] SCARA, End-Effector, Cable Bot
            \item[Specifications:]  1, 2, 3, (12)
            \item[Requirements:]  1, 2, 3, (12)
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item All lines are drawn, 11 vertical and 4 horizontal lines.
@@ -118,7 +118,7 @@ the quick brown fox jumps over the lazy dog!?@,.-
        \tcbline
        \begin{description}
            \item[Features:] SCARA, End-Effector, Cable Bot
            \item[Specifications:] 1, 2, 3, 4, (5), 6, 7, 12, 13, 14, 15, 16
            \item[Requirements:] 1, 2, 3, 4, (5), 6, 7, 12, 13, 14, 15, 16
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item The text as described is readable from a atleast \SI{4}{\meter} distance.
@@ -133,7 +133,7 @@ the quick brown fox jumps over the lazy dog!?@,.-
        \tcbline
        \begin{description}
            \item[Features:] SCARA, End-Effector, Cable Bot
            \item[Specifications:] (5), 10, 11, 12
            \item[Requirements:] (5), 10, 11, 12
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item The system cleaned the board within \SI{60}{\second}.
@@ -147,7 +147,7 @@ the quick brown fox jumps over the lazy dog!?@,.-
        \tcbline
        \begin{description}
            \item[Features:] SCARA, End-Effector, Cable Bot
            \item[Specifications:] 8
            \item[Requirements:] 8
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item The developer can motivate that the system is complex enough to evaluate the case study.
--- a/content/background.tex
+++ b/content/background.tex
@@ -1,38 +1,28 @@
 %&tex
 \chapter{Background}
 \chapter{Starting Point}
 \label{chap:background}
 Engineers have many different types of design methods available in their fields.
 Examples of these are Agile, Spiral, V model, and Waterfall.
 Each of these design methods start with a need and develop a product to satisfy that need.
 From an extremely basic point of view, these methods start with a preliminary design where the need is translated into an initial design, requirements, and specifications.
 This initial design is implemented into a product and the product is tested.
 The preliminary design is often similar between the different design methods, but the methods differentiate on their implementation and testing phase. 
 \textcite{broenink_rapid_2019} do not provide a complete design method and focus on their implementation and testing method.
 To create a complete design plan that can be used in the case study, I used the waterfall model in the \ac{se} approach as a basis for the design plan.
 The techniques of the \ridm replace the implementation and testing phase of the waterfall model.
 This chapter will introduce the basics of \ac{se} and the waterfall model, and analyse what the \ridm provides.
 The goal of the design plan is to develop a \ac{cps}.
 Due to the nature of \ac{cps}, it involves a multi-domain design approach.
 Therefore, the subject of \ac{se} is relevant to this approach.
 Furthermore, the \ac{ridm} is discussed in more detail in this chapter.

 The \ac{ridm} does not initiate from the problem description step.
 As this step is required a design from scratch, the \ac{ridm} is combined with the approach from \ac{se} establish the required design steps.

 \section{Systems Engineering}
 \label{sec:SE}
 \begin{marginfigure}
    \centering
    \includegraphics[width=2.9cm]{graphics/waterfall.pdf}
    \caption{Minimalistic implementation of waterfall model.}
    \label{fig:waterfall}
 \end{marginfigure}
 \textcite{blanchard_systems_2014} describe \ac{se} in their book as: "an interdisciplinary approach and means to enable the realization of successful systems."
 Their book extensively covers multiple design methods and design steps in detail.
 The simplest of these design method is the waterfall model.
 This waterfall model consists of number of steps that are all successively executed as shown in \autoref{fig:waterfall}.
 The successive steps make it possible to insert or replace the steps in the design method.
 For this thesis, their approach on \emph{Bringing a Systems into Being} and \emph{Preliminary System Design} are especially relevant.
 \ac{se} is a complete field of engineering on its own and only the top of the iceberg is used in this thesis.

 \section{Rapid Iterative Design Method}
 \label{sec:RIDM}
 The \ridm by \textcite{broenink_rapid_2019} describes a methodology using two core components for the implementation: the rapid development cycle and the variable detail approach.
 The \ac{ridm} by \textcite{broenink_rapid_2019} describes a methodology using two core components for the implementation: the rapid development cycle and the variable-detail approach.
 The design method also describes the preparation steps that are required prior to this implementation.
 In short, the preparation prepares a list of features.
 These features are implemented one by one with in the rapid development cycle using the variable detail approach.
 This section discusses each of these three parts and how they fit in the waterfall model.
 These features are implemented one by one with in the rapid development cycle using the variable-detail approach.
 The following sections discus each of these three design steps.

 \subsection{Rapid Development Cycle} 
 \label{sec:background_rdc}
@@ -44,35 +34,46 @@ Each iteration of the rapid development incorporates the following steps:
 \end{enumerate}
 The first step is to create an initial design and tests that are used to verify the requirements of the current feature.
 During the second step, the initial design is developed into a detailed design of the feature.
 This detailed design of the feature is develop with the variable detail approach, in which the level of detail is stepwise incremented.
 This detailed design of the feature is develop with the variable-detail approach, in which the level of detail is stepwise incremented.
 When the second step is completed, the implemented feature contains all the required details and passes all the tests as defined in the first step.
 From this point the rapid development cycle is repeated for the next feature, or, when no features are left, finish the development.

 \subsection{Variable Detail Approach}
 The variable detail approach starts with a low-detailed model and increases the detail discretely over multiple iterations.
 \subsection{Variable-Detail Approach}
 The variable-detail approach starts with a low-detailed model and increases the detail discretely over multiple iterations.
 The low-detailed model is for example a single transfer function of the system.
 In the following iteration, the detail of the model is increased by adding, for example, non-linearity, non-continuity or parasitic elements.

 The tests, as specified in the first step of the rapid development cycle, are performed after each addition of detail.
 If the tests show that the added detail is not conform the specifications, the added detail is reviewed or redesigned.
 If the tests show that the added detail is not conform the requirements, the added detail is reviewed or redesigned.
 When the added detail passes the tests, the process is repeated to add more detail.
 The variable detail approach is finished when all the tests are passed and all the detail is added.
 The variable-detail approach is finished when all the tests are passed and all the detail is added.

 \subsection{Preparation steps}
 Although the \ac{ridm} does not specify the complete steps for the preparation, it does state some requirements.
 The rapid development cycle requires a list of features that can be implemented and tested individually.
 These features are gained by partitioning the functionality of the system.

 \subsection{Preparation}
 Although the \ridm does not specify the complete steps for the preparation, it does state some requirements.
 The rapid development cycle requires a list of features that can be implemented one by one.
 These features are gained by partitioning the functionality of the system, such that features can be implemented and tested individually.
 For each feature it is required to specify the feature requirements and the corresponding test protocol.
 The feature requirements are based on the system requirements and the tests are used to validate that the feature meets its requirements.
 About the order of implementation, the \ridm states that critical features should be implemented first, as these features have an increased chance of invalidating the complete design.
 About the order of implementation, the \ac{ridm} states that critical features must be implemented first, as these features have an increased chance of invalidating the complete design.
 Would such a feature fail, the investment loss is limited, because the development is still in an early stage.

 \section{Combination}
 Following the feature separation step is the system test protocol.
 The goal of this step is to describe how the requirements of the system are tested.
 These tests can cover a single feature or multiple features.

 \begin{marginfigure}
    \centering
    \includegraphics[width=6cm]{graphics/design_flow.pdf}
    \caption{Combined design plan, where the first three steps are based on the waterfall model and the other four steps are taken from the \ac{ridm} \autocite{broenink_rapid_2019}}
    \includegraphics[width=55mm]{graphics/design_flow.pdf}
    \caption{Combined design plan, where the first three steps are based on the \ac{se}-approach and the other four steps are taken from the \ac{ridm} \autocite{broenink_rapid_2019}}
    \label{fig:design_flow}
 \end{marginfigure}
 As the \ridm integrates the implementation and testing steps together, it replaces these steps in the waterfall model.
 The first three steps as seen in \autoref{fig:waterfall} are unchanged and the last two steps are replaced by the \ac{ridm}.
 A combined design flow of the both design methods is shown in \autoref{fig:design_flow}.
 \section{Combination}
 To create a complete design plan, design approaches from both \ac{se} and the \ac{ridm} are combined.
 The \ac{ridm} requires an initial design that is then split into features.
 To meet this requirement, a linear set of steps from problem description to initial design is used from \ac{se}.
 These three steps are shown at the top of \autoref{fig:design_flow} in the \acl{se} group.
 The steps show some similarity with the first steps of a V or Waterfall model.

 The requirements and initial design are used in the four steps of \ac{ridm} continue the design process.
 These four steps are grouped at the bottom of \autoref{fig:design_flow}.
--- a/content/case_evaluation.tex
+++ b/content/case_evaluation.tex
@@ -1,75 +1,67 @@
 %&tex
 \chapter{Case Study: Evaluation}
 \label{chap:case_evaluation}
 \begin{marginfigure}
    \centering
    \includegraphics[width=51mm]{graphics/model_versions.pdf}
    \caption{
        Levels of detail of the design are shown on the right, starting with the least detail at the top and most detail at the bottom. 
        Through out the development different types of models are used, these are shown on the left.
    }
    \label{fig:levels}
 \end{marginfigure}
 The previous chapter described the development and implementation process of the Whiteboard Writer.
 This chapter focusses on the evaluation of the development during the case study.
 The design method itself is evaluated in the next chapter.
 However, some of the topics discussed in this chapter have a strong overlap with those in the next chapter.

 The first section gives a short overview of results of the case study.
 Then a section is about the time spend on the development.
 Followed by two sections on the role of stake holders and the use of modelling languages during a development.
 The last section is a more personal reflection about the development.

    \section{Result}
    \input{content/case_evaluation_result.tex}
 The first section is about the time spend on the development.
 Followed by a section about the role of stake holders and one about the use of modelling languages during a development.
 The last section is a more personal reflection about the case study.

    \section{Time Investment}
    \label{sec:time_investment}
        Prior to each step in the development, I made an estimation on the workload of that particular step.
        In \autoref{fig:time_spend} the planned and spend time on each step are plotted next to each other.
        Five of these steps were completed in the planned number of days.
        However, three steps required more time than expected.
        As evaluated in \autoref{sec:case_featuredefinition_evaluation}, the proposed design method for the feature definition was not feasible.
        Documenting and solving the problem resulted in a delay of seven days.
        The second development cycle experienced a delay of four days.
        This was a underestimation of the time needed to complete the step.
        In addition to the steps, time was also spend on the hardware construction and software development.

        The initial approach for the feature definition did not result in a statisfactory set of features.
        Therefore, the approach for the feature definition was reformulated.
        Before new approach was formulated, multiple attempts were made to get a representative set of features.
        The time spend on performing the feature definition is not representative as formulating the new approach and creating the set of features were performed in parallel.
        The real execution time is estimated to be around 3 to 5 days ( {\textsuperscript{1} in \autoref{fig:time_spend}).

        \begin{figure}
            \centering
            \includegraphics{graphics/time_table.pdf}
            \caption{Overview of the planned and spend number of days for each step during the case study. For Development Cycle 1 three days were planned for the initial development, based on the outcome I decided to abandon this cycle. Therefore, no additional time was planned nor spend on the development.}
            \caption{
                Overview of the planned and spend number of days for each step during the case study. 
                Some of the values in this do not represent the time requirements of this design method:\newline
                \textsuperscript{1} During the feature definition the design method was reviewed. 
                13 days were spend on this review and execution, obfuscating the actual execution time. 
                The execution time is an estimated 3 to 5 days.\newline
                \textsuperscript{2} The first cycle was cut short due to its complexity.\newline
            }
            \label{fig:time_spend}
        \end{figure}
        Furthermore, there is a significant difference between the planned number of days for both development cycles.

        Furthermore, there is a significant time difference both development cycles.
        Prior to the first development cycle I was not confident about the feasibility of the end-effector implementation.
        Based on that, I decided to spend about three days on the basic model of the end-effector to collect more information.
        This let me to the conclusion that the end-effector was too time-consuming for this case study.
        Therefore, first development cycle was cut short ( \textsuperscript{2} in \autoref{fig:time_spend})

        For the second cycle, I also planned three days to create the basic model.
        This time, the basic model was finished within a couple of hours.
        Based this early success and prior experience, I planned an additional two weeks of development time for this cycle.
        Based on this successful implementation and prior experience, I planned an additional two weeks of development time for this cycle.

        Although not directly part of the design method, I did build a prototype.
        This consisted of acquiring and assembling the hardware, and writing software.
        To validate the design and model of the \ac{scara}, I build a prototype.
        This consisted of building the hardware and writing software.
        Acquiring and assembling the hardware took about two days.
        This was mainly due to CoViD-19 restrictions which made part ordering and printing more challenging.
        Without these restrictions I think it would be a day of work.
        However, the time required to get the software to a viable state was four weeks.

        Even though, the focus was not on the software, this timespan of four weeks is too significant to ignore.
        The time required to get the software to a viable state was four weeks.
        Even though the focus was not on the software, this timespan of four weeks was too significant to ignore.
        Especially when the software is compared to the developed models.
        As explained in the previous section, I build a total of eight models.
        Each of these models includes documentation and an evaluation of the design process.
        The software, on the other hand, is in a bare minimum state; I skipped documentation and evaluation; and the code quality relatively low.
        Still, the software was more time consuming than the hardware modeling and development.

        \textcite{royce_managing_1970} also acknowledges this difference in complexity for soft- and hardware.
        He expects 50 pages of software documentation for each page of hardware documentation in projects with comparable budget.
        \textcite{sheard_718_1998} discusses multiple points about the difference between soft- and hardware.
        The point that is most applicable to this case study is that pure-hardware solution are relatively simple in their problem-space perspective.
        However, the hardware solution is often complex in the solution space perspective.
        The inverse is true for software.
        Thus, a complex system is easier to implement with software.

    \section{One-man development team}
        The case study was performed by me, as a single developer.
        The case study was performed by me as a single developer.
        Against all expectations, this one-man development team made the preparation phase more difficult instead of easier.
        The goal of the problem description and the requirements step is to get the stakeholders on the same line \autocite{shafaat_exploring_2015}.
        This involves creating agreed-upon requirements for the system, but with only one stakeholder, this agreement is implicit.
@@ -77,7 +69,7 @@ The last section is a more personal reflection about the development.
        Part of this is that there is no penalty for future reviews of the requirements, as I already agreed.

        Furthermore, specific details and decisions were often made subconsciously, while I was commuting, waiting in line, or even showering.
        Making structured documentation of these decisions at a later point in time without missing any of them was impossible.
        Making structured documentation of these decisions at a later point in time without missing any of them is impossible.
        The social interaction within a design team stimulates this documenting process as it improves the recall and interpretation of information.
        It also improves the judgement and selection of design alternatives \autocite{lamb_221_2008}.

@@ -93,12 +85,12 @@ The last section is a more personal reflection about the development.
        Resulting in a fourth model which represents the mechanical component design, in the form of a CAD drawing.
        
        There are a couple of problems with this approach.
        Implementing the same model with a different modelling approach, makes both models incompatible with each other.
        Implementing the same model with two different modelling approaches, makes both models incompatible with each other.
        This removes the possibility to switch back to a lower detail implementation.
        Additionally, it creates the possibility to transfer parameters incorrectly from one model to another.
        Such a switch is also labor intensive as the complete model has to be build from scratch again.
        Furthermore, there is the possibility that this new model has been for nothing, as the planned detail proves to be unfeasible.
        The point is, a future iteration of the design method must avoid these type of model switches.
        The point is, a future iteration of the design method must minimize these type of model switches to reduce the chance of implementation errors.

    \section{Reflection}
        In the following section, I reflect on my own impact on the development.
@@ -106,11 +98,11 @@ The last section is a more personal reflection about the development.

        \subsection{Preparation phase}
            During the preparation phase often I had difficulty with getting the required information.
            The information was often not specific enough or it it was overlooked.
            The information was often not specific enough or it was overlooked.
            Even though attempting to be thorough, requirements were never really specific.
            As explained in the previous section, the lack of stake-holders is one of the reasons for information not being specific.
            Furthermore, during the preparation information was often overlooked.
            Resulting in a situation where I needed information that should have been the result of a previous step, which was not the case.
            
            Information that was overlooked created a situation where I needed information that should have been the result of a previous step, which was not the case.
            In most situations it was possible to continue with the execution of the step.
            However, during the test protocol step (\autoref{sec:test_protocol}) it was not possible to continue.
            Resulting in additional requirements added to the design, before continuing with the design process.
@@ -120,7 +112,7 @@ The last section is a more personal reflection about the development.
            Being inexperienced does definitely not aid the design process. 
            Needless to say, more experience would improve the information situation. 
            However, it does not solve the problem.
            Further improvements for the design method is required, to improve the information process during development.
            Further improvements for the design method are required to improve the information process during development.
            
        \subsection{Development phase}
            \label{sec:evaluation_reflection_development}
@@ -132,8 +124,7 @@ The last section is a more personal reflection about the development.
            For example, the \ac{scara} and the \ac{cdc} both include two stepper motors.
            When I add detail to the stepper motor model, the \ac{scara} and the \ac{cdc} would then be updated as well.
            However, each sub-model has to be updated manually.
            In total four times in case of the stepper motor.
            Which makes this workflow very labor intensive.
            In total four times in case of the stepper motor, which makes this workflow very labor intensive.

            A workflow that enables easy combination and interchange of sub-models is beneficial with this design method.
            It makes it easy to evaluate the latest changes, by comparing them with previous versions.
@@ -143,12 +134,15 @@ The last section is a more personal reflection about the development.

        \subsection{Continuation of this Case Study}
            \label{sec:evaluation_reflection_protoype}
            At the point that the SCARA was implemented, I gathered so much new information that the some of the design choices felt obsolete.
            Although, the current design method does not incorporate a prototype, the current state of the design is more or less a prototype.
            At the point that the \ac{scara} was implemented, I gathered so much new information that some of the design choices felt obsolete.
            In this case study, the prototype is used to validate the design.
            However, the current prototype contains so much information that it would improve the requirements and initial design significantly.
            
            Following the current design plan, the next step would be to develop the \ac{cdc}.
            In theory, if I would continue the case study, my proposal is to consider the current design as an actual prototype and revisit the preparation phase.
            With the current knowledge, the specifications and initial design would improve significantly.
            However, it is very important to note that this decision relies on the fact that the prototype is already created.
            In other words, the work is already done and resulted in useful information for a next design iteration.
            But, in case of a different system, I doubt that creating a prototype, followed by a full repeat of the design method is an efficient approach.
            Therefore, the choice to revisit the preparation phase must not be considered as an improved design method but as an argument to improve the preparation phase itself.

            In case of a different system, I doubt that creating a prototype, followed by a full repeat of the design method is an efficient approach.
            Therefore, the choice to revisit the preparation phase must not be considered as an improved design method but as an argument to improve the preparation phase itself.
            However, I think that an improved preparation phase must be shorter and incorporate a prototype.
--- a/content/case_evaluation_result.tex
+++ b/content/case_evaluation_result.tex
@@ -1,13 +1,27 @@
 %&tex
 \section{Result}
 \label{sec:result}
 In the end, the development produced eight models with increasing levels of detail and one prototype.
 The different levels of detail and how they are modelled are shown in \autoref{fig:levels}.
 The assembled \ac{scara} prototype is shown in \autoref{fig:prototype}.
 This prototype is able execute the small rectangle as described in \autoref{test1}, and thus passes the test.

 As the \ac{cdc} was not finished, a small stand was build to test the \ac{scara}.
 The assembled \ac{scara} prototype on the stand is shown in \autoref{fig:prototype}.
 This prototype is able to execute the small rectangle as described in \autoref{test1}, and thus passes the test.
 In addition, it was possible to write three characters. Therefore, passing \autoref{test_triple_char}.

 \begin{figure}
 \begin{marginfigure}
    \centering
    \includegraphics[width=51mm]{graphics/model_versions.pdf}
    \caption{
        Levels of detail of the design are shown on the right, starting with the least detail at the top and most detail at the bottom. 
        Through out the development different types of models are used, these are shown on the left.
    }
    \label{fig:levels}
 \end{marginfigure}

 \begin{figure*}[t]
    \hspace{5mm}
    \includegraphics[width=96mm]{graphics/prototype.JPG}
    \caption{Assembled prototype of the \ac{scara}.}
    \includegraphics[width=\linewidth]{graphics/scara_test.JPG}
    \caption{Assembled prototype of the \ac{scara}. The \ac{scara} passed \autoref{test1} drawing the perimeter and passed \autoref{test_triple_char} with the characters $123$.}
    \label{fig:prototype}
 \end{figure}
 \end{figure*}
--- a/content/case_experiment.tex
+++ b/content/case_experiment.tex
@@ -4,23 +4,23 @@
 This chapter presents the execution of the case study.
 Where the goal of the case study is to evaluate the design plan as presented in \autoref{chap:analysis}.
 To achieve this goal, I develop a system according to the design plan and document this design process.
 As described in \autoref{sec:sod}, the system to be designed is a "Tweet on a Whiteboard Writer".
 As described in \autoref{sec:sod}, the subject of design is a "Tweet on a Whiteboard Writer".
 Documenting the process is done by following the evaluation protocol as described in \autoref{sec:evaluation_protocol}.
 To start the case study unbiased, during the preparation I did perform as little preliminary research as possible on the design options of the whiteboard writer.

 The chapter begins with the section about the preparation phase, which contains the four corresponding design steps as shown in \autoref{fig:design_plan_analysis}.
 The chapter begins with the section about the preparation phase, which contains the five steps from problem description to test protocol step as shown in \autoref{fig:design_plan_analysis}.
 This is followed by two completed development cycles in the later two sections.
 Both of these sections cover the three steps that are shown in \autoref{fig:design_plan_analysis}.
 Each design step is described in a separate subsection.
 Herein, the result of the design step is presented and concluded with an evaluation section at the end.
 Both of these sections cover the feature selection, variable-detail approach and rapid development steps as shown in \autoref{fig:design_plan_analysis}.
 Each design step is described in a separate section.
 Herein, the result of each design step is presented and concluded with an evaluation section at the end.
 This evaluation section discusses the pairs of questions that were answered according to the evaluation protocol (\autoref{tab:prepost}).
 The questions regarding the design method itself are discussed in \autoref{chap:reflection}.

 \section{Preparation Phase}
 The preparation phase contains four design steps.
 It begins with a problem description.
 This description is detailed into a list of specifications.
 Based on the specifications, a number of design solutions proposed and eventually one of these solutions is chosen as initial design.
 The problem description is used to create a list of system requirements.
 Based on the requirements, a number of design solutions proposed and eventually one of these solutions is chosen as initial design.
 Splitting the initial design into features is done in the feature definition step.

 \input{content/case_experiment_problem_description.tex}
@@ -37,4 +37,3 @@ Splitting the initial design into features is done in the feature definition ste

 \section{System Design Validation}
 \input{content/case_experiment_prototype.tex}

--- a/content/case_experiment_end-effector.tex
+++ b/content/case_experiment_end-effector.tex
@@ -1,49 +1,52 @@
 With the preparation phase completed, the development cycle is next.
 This consists of three steps: Feature selection, Rapid Development and Variable Approach.
 This consists of three steps: Feature selection, Rapid Development and Variable-detail Approach.
 The current section explains the first development cycle during the design.
 For this first cycle of the design process, I design the end-effector.
 However, not long after the start of the development process, the implementation proved to be too complex.
 However, not long after the start of the development process, the implementation of the end-effector proved to be too complex.
 This led to the decision to abort the implemention of the end-effector.
 Eventhough no progress was made, this attempted implementation did provide valuable insight in the desing process.
 Eventhough no progress was made in the design, this attempted implementation did provide valuable insight in the desing process.

    \subsection{Feature Selection}
        \label{sec:case_feature_selection_1}
        \begin{table}[]
            \caption{Overview of the different features and their dependencies, number of tests that are covered and the risk/time factor.
            The risk/time factor is calculate as risk divided by time.}
        For each feature in the system the dependees, tests and \ac{cof}/time factor is determined, as explained in \autoref{sec:feature_selection}.
        These values are combined into \autoref{tab:firstfeatureselection}.
        \begin{table}[h]
            \caption{Overview of the different features and their dependencies, number of tests that are covered and the \ac{cof}/time factor.
            The \ac{cof}/time factor is calculate as \ac{cof} divided by time.}
            \label{tab:firstfeatureselection}
            \begin{tabular}{|l|l|l|l|l|l|}
                \hline
                Feature      & Dependees   & Tests  & Risk   & Time    & Risk/Time  \\ \hline
                \ac{scara}        & -           & 3      & 40\%   & 10 days & 4          \\ \hline
                End-effector & \ac{scara}       & 2      & 60\%   & 8 days  & 7.5        \\ \hline
                \ac{cdc}     & -           & 2      & 30\%   & 10 days & 3          \\ \hline
            \rowcolors{2}{lightgray}{white!100}
            \begin{tabular}{llrrrr}
                \toprule
                Feature      & Dependees   & Tests  & \ac{cof}   & \multicolumn{1}{l}{Time}    & \ac{cof}/Time  \\ 
                \midrule
                \ac{scara}        & $-$           & $3$      & $40\%$   & $10$ days & $4  $        \\ 
                End-effector & \ac{scara}         & $2$      & $60\%$   & $8$ days  & $7.5$        \\ 
                \ac{cdc}     & $-$                & $2$      & $30\%$   & $10$ days & $3  $        \\ 
                \bottomrule
            \end{tabular}
        \end{table}
        For each feature in the system the dependees, tests and risk/time factor is determined, as explained in \autoref{sec:feature_selection}.
        These values are combined into \autoref{tab:firstfeatureselection}.

        The \ac{scara} depends on the end-effector, as explained in the initial design.
        However, for the \ac{cdc} no dependency was defined even though it has to lift the other two components.
        This is mainly because the torque and range requirements of the \ac{scara} depending on the implementation of the end-effector.
        This is mainly because the torque and range requirements of the \ac{scara} depend on the implementation of the end-effector.
        Especially the required range depends on the method of grabbing and releasing tools.
        For the \ac{cdc} it only changes the mass that has to be lifted.
        Upgrading the motor torque is a minor parametric change and the dependency is therefore insignificant.
        Upgrading the motor torque is a minor parametric change and the dependency is therefore deemed insignificant.

        The testing number is directly the number of tests that apply to that feature.
        The risk and time values are not determined with a specific protocol, but with simple engineering judgement.
        The estimated risk is high for the end-effector due to the collision dynamics of the operation.
        The \ac{cof} and time values are not determined with a specific protocol, but with simple engineering judgement.
        The estimated \ac{cof} is high for the end-effector due to the collision dynamics of the operation.
        It has to grab something and that is difficult to model. Furthermore, it was not known if that design would work.
        The \ac{scara} has the most moving parts, but no difficult dynamics and has therefore an estimated risk of medium.
        For the \ac{cdc} there was no real risks and got therefore a low risk indication.
        The \ac{scara} has the most moving parts, but no difficult dynamics and has therefore an estimated \ac{cof} of medium.
        For the \ac{cdc} there was no real \ac{cof} and got therefore a low \ac{cof} indication.
        
        Based on \autoref{tab:firstfeatureselection}, the end-effector is implemented first.
        The end-effector has the most dependees, and is therefore chosen above the other two.

        \subsubsection{Evaluation}
            This first step of the detail design phase did go well.
            Although risk and time assessment is always depend on some engineering judgment, this human factor introduces uncertainty in the assessment.
            However, an improved approach for the risk assesment can drastically reduce this human factor.
            Although \ac{cof} and time assessment is always depend on some engineering judgment, this human factor introduces uncertainty in the assessment.
            However, an improved approach for the \ac{cof} assessment can drastically reduce this human factor.
            Within a design team a form of planning poker \autocite{grenning_planning_2002} could be a good option.
        
    \subsection{Rapid Development of the End-Effector}
@@ -52,33 +55,29 @@ Eventhough no progress was made, this attempted implementation did provide valua
        The first step is to create an initial design of the model.
        In subsequent steps, detail is added to this model.

        The previous section explained the relative high risk assessment  for the end-effector.
        The previous section explained the relative high \ac{cof} assessment for the end-effector.
        Which was not exaggerated as the implementation proved to be troublesome.
        Eventually, the implementation was unfeasible and was therefore cut short.
        Nonetheless did it result in useful evaluation points on the design method.
        The process of this step is explained in the following sections.


        The development starts with an initial design of the system.
        The next step is to develop that further into a model and prototype.
        This development did not get past the basic model implementation due to unforeseen difficulties.
        However, the evaluation gave new useful insight on the design plan.

        \subsubsection{Initial design}
            The end-effector is mounted on the \ac{scara} and acts as an interface.
            With the end-effector, the \ac{scara} is able to grab and release tools.
            There are multiple approaches to handle these tools.
            The end-effector is mounted on the \ac{scara} and acts as an interface for the tooling.
            The \ac{scara} and end-effector combined are able to grab and release the write and erase tooling.
            There are multiple approaches to handle the tooling.
            However, there is a trade-off to be made with the \ac{scara} feature, the heavier the end-effector is, the more force the \ac{scara} must deliver.
            And because the goal is to make the \ac{scara} light and quick, this end-effector must be light-weight as well.

            The best options in this case is a simple spring-loaded clamp.
            To release the tool, the clamp is forced open, pushing it against the holder.
            As the end-effector is connected to the \ac{scara}, the \ac{scara} is responsible for the pushing force.
            Because the actuation force of the \ac{scara} is used, it removes the need for an additional servo in the end-effector.
            Resulting in a simpler and lighter design.

            The initial design of the clamp and the operation is shown in \autoref{fig:gripper}. 
            Although this design requires the \ac{scara} to deliver more force.
            The relative low mass of the end-effector also keeps the moment of inertia small.
            Therefore, the current design reduces the impact on the acceleration of the \ac{scara} to a minimum.
            Therefore, the current design reduces the impact on the acceleration of the \ac{scara}.
            \begin{figure*}
                \centering
                \includegraphics[width=151mm]{graphics/end-effector.pdf}
@@ -93,17 +92,18 @@ Eventhough no progress was made, this attempted implementation did provide valua
            Based on some experience in modelling with collisions, I decided to use the 20-sim 3D mechanics editor.
            Unfortunately, there is little tooling available and there are no debugging options if the model does not behave as expected.
            The marker kept falling trough the gripper or flew away.

            With the small amount of progress made in two days the implementation was not promising. 
            A system freeze caused the model to corrupt, where the complete configuration of the shapes and their collisions was lost.
            Based on the loss of work and the low feasibility of the implementation, the decision was made to remove the end-effector from the design.

            With the end-effector removed, the \ac{scara} gets a direct connection with the marker.
            The lifting of the marker from the is included in the \ac{scara} as well.
            Furthermore, this means that the erasing is no longer possible as a feature.
            Lifting and lowering the marker is included in the \ac{scara} feature as well.
            Unfortunately, this means that switching to the eraser is not longer possible as functionality.

        \subsubsection{Evaluation}
            The lost progress of the model is unfortunate, but the implementation did not go as expected anyway.
            It was probably for the best as it forced an evaluation of the design and avoided a tunnel vision while trying to get it to work.
            However, it did show the value of the risk/time analysis.
            However, it did show the value of the \ac{cof} per time analysis.
            This early failure resulted in changes for other components.
            But as none of the components were implemented yet, no work was lost.
            But as none of the other components are implemented yet, no work is lost.
--- a/content/case_experiment_feature_definition.tex
+++ b/content/case_experiment_feature_definition.tex
@@ -1,51 +1,68 @@
 %&tex
 \subsection{Feature Definition}
    \label{sec:case_featuredefinition}
    This step divides the specifications and initial design into features. 
    These features will be implemented one by one during the development cycle, later in the process.
    However, the initial set of features did not meet the expected set of features.
    This led me to review how the features are defined.
    The following sections explain what the problem caused and how it is solved.
    This step divides the requirements and initial design into features. 
    These features are implemented one by one during the development cycle, later in the process.
    As described in \autoref{sec:featuredefinition}, the functionality of the system is split over four different levels of abstraction.
    The result of this split is shown \autoref{fig:robmosys}.
    
    \begin{figure*}
        \centering
        \includegraphics[width=136mm]{graphics/robmosys.pdf}
        \caption{Hierarchical tree of different functions and components.}
        \label{fig:robmosys}
    \end{figure*}

    \subsubsection{Splitting the features}
        The first issue was the lack of a clear border between features.
        Thus, depending on where the developer places that border, the set of features changed significantly.
        For example, the main functionality is \emph{writing a tweet on a white-board.}
        A clear feature of this functionality is \emph{writing}.
        However, must the \emph{writing} be split in a feature for writing a line, a word, or single character?
        Moreover, it is also possible to argue that \emph{writing one character} a sub-feature of \emph{writing a word}, which in itself is a sub-feature of \emph{writing a line} etcetera.
    \subsubsection{Evaluation}
    \label{sec:case_featuredefinition_evaluation}
        The mission and task features are easy to define.
        The skill and service features become a bit more vague, often features fit in both categories.
        Sometimes it is difficult to split a skill into a service, as they are already very specific.
        Additionally, I attempted to keep the feature tree a bit compact, to keep in scope with this thesis.

    \subsubsection{Missing features}
        The second issue was that the resulting set of features did not contain any of the expected features.
        From the initial design it was expected that the features must include a SCARA and a cable driven carriage, because they make the system and have to be implemented somewhere in the process.
        However, independent of how the functionality was split into features, no SCARA nor cable driven carriage was included in the set of features.
        Which is not surprising as the SCARA and carriage do not define any functionality and can therefore not be a result from the current approach.
        This mismatch between results and expectation together with the ambiguity of splitting features called for a review the design method regarding the current step.
        The components also use a similar approach as the functions, resulting in a hierarchical structure of sub-components, where the \ac{scara} would have motors and electronics as sub-components.
        
        \begin{figure*}
            \centering
            \includegraphics[width=136mm]{graphics/robmosys.pdf}
            \caption{Feature Definition based on the separation of levels introduced by RobMoSys}
            \label{fig:robmosys}
        \end{figure*}
    \subsubsection{Feature and Component Hierarchy}
        The solution for both issues is a hierarchical structure for the features.
        The structure is based on the RobMoSys principle for separation of levels \autocite{noauthor_robmosys_2017}.
        The top-level of the structure is the mission, which represents the higher level goal of the system.
        Each mission consists of a number of tasks, where each task consists of a number of skills.
        The levels cascade down towards the bottom-level for RobMoSys, which is the hardware layer.
        Although not all the different levels from the RobMoSys principle were applicable to the design method in this study, it enabled me to create the feature definition as shown in \autoref{fig:robmosys}.
        In this feature definition, the levels from mission to function are used to describe the different features of the system.
        The mission describes the holistic functionality of the system.
        The subsequent levels all split off in more detailed behavior.
        The bottom level is used to describe the hardware components which are responsible for performing the functions of the system.
        This hierarchy allows to implement features or components one by one, starting from the bottom and combining this into a system towards the top.
 %        Even though there is a feature definition that can be used in the next step, there remain a couple of difficulties.
 %        There is still a clear separation between features and components.
 %        And the single level of components makes it impossible to depict the dependencies between components.
 %        Developing larger and complex systems will have sub-components in the system, introducing even more dependencies.
 %        Therefore, this is not a valid solution for feature definition.
 %        Fortunately the current solution suffices to continue the case study.

    \subsubsection{Evaluation}
    \label{sec:case_featuredefinition_evaluation}
        Even though there is a feature definition that can be used in the next step, there remain a couple of difficulties.
        There is still a clear separation between features and components.
        And the single level of components makes it impossible to depict the dependencies between components.
        Developing larger and complex systems will have sub-components in the system, introducing even more dependencies.
        Therefore, this is not a valid solution for feature definition.
        Fortunately the current solution suffices to continue the case study.
    %%%%%%%%%%%%%%%%%%%%%%%
 %    It was however not possible to describe the all aspects of the design with features.
 %    I found that the design method did not take components into account.
 %
 %    
 %
 %    However, the initial set of features did not meet the expected set of features.
 %    This led me to review how the features are defined.
 %    The following sections explain what the problem caused and how it is solved.
 %
 %    \subsubsection{Splitting the features}
 %        The first issue was the lack of a clear border between features.
 %        Thus, depending on where the developer places that border, the set of features changed significantly.
 %        For example, the main functionality is \emph{writing a tweet on a white-board.}
 %        A clear feature of this functionality is \emph{writing}.
 %        However, must the \emph{writing} be split in a feature for writing a line, a word, or single character?
 %        Moreover, it is also possible to argue that \emph{writing one character} a sub-feature of \emph{writing a word}, which in itself is a sub-feature of \emph{writing a line} etcetera.
 %
 %    \subsubsection{Missing features}
 %        The second issue was that the resulting set of features did not contain any of the expected features.
 %        From the initial design it was expected that the features must include a SCARA and a cable driven carriage, because they make the system and have to be implemented somewhere in the process.
 %        However, independent of how the functionality was split into features, no SCARA nor cable driven carriage was included in the set of features.
 %        Which is not surprising as the SCARA and carriage do not define any functionality and can therefore not be a result from the current approach.
 %        This mismatch between results and expectation together with the ambiguity of splitting features called for a review the design method regarding the current step.
 %        
 %    \subsubsection{Feature and Component Hierarchy}
 %        The solution for both issues is a hierarchical structure for the features.
 %        The structure is based on the RobMoSys principle for separation of levels \autocite{noauthor_robmosys_2017}.
 %        The top-level of the structure is the mission, which represents the higher level goal of the system.
 %        Each mission consists of a number of tasks, where each task consists of a number of skills.
 %        The levels cascade down towards the bottom-level for RobMoSys, which is the hardware layer.
 %        Although not all the different levels from the RobMoSys principle were applicable to the design method in this study, it enabled me to create the feature definition as shown in \autoref{fig:robmosys}.
 %        In this feature definition, the levels from mission to function are used to describe the different features of the system.
 %        The mission describes the holistic functionality of the system.
 %        The subsequent levels all split off in more detailed behavior.
 %        The bottom level is used to describe the hardware components which are responsible for performing the functions of the system.
 %        This hierarchy allows to implement features or components one by one, starting from the bottom and combining this into a system towards the top.
--- a/content/case_experiment_initial_design.tex
+++ b/content/case_experiment_initial_design.tex
@@ -1,25 +1,25 @@
 %&tex
    \subsection{Initial design}
    \subsection{Initial Design}
    \label{sec:initialdesign}
        The initial design started with a design space exploration.
        The goal was to collect possible solutions and ideas for the implementation.
        The exploration resulted in a lot of whiteboard writing robots ideas.
        These robots can be sorted in four different configurations
        These robots are sorted in four different configurations.
        Each configuration explained in the following sections.
        From the possible configurations, the one that fits the specifications best, is made into an initial design.
        From the possible configurations, the one that fits the requirements best, is made into an initial design.
        
        \subsubsection{Cable-Driven}
            The cable-driven robot is suspended with multiple cables.
            The end-effector that contains the marker is moved along a board by changing the length of the cables.
            The cable-based positioning systems result in an end-effector with a large range and high velocities.
            A basic setup can be seen in \autoref{fig:cablebotdrawing}.
            The cable-based positioning system results in an end-effector with a large range and high velocities.
            A basic setup is shown in \autoref{fig:cablebotdrawing}.
            This given setup contains two cables that are motorized.
            The big advantage of this system is that it scales well, as the cables can have almost any length.
            \begin{figure}
                \centering
                \includegraphics[width=10.8cm]{graphics/cablebot.pdf}
                \caption{Planar view of cable driven robot. This setup contains two motorized pulleys in both top corners. From these two cables a mass is suspended at position $x,y$.
                By changing the length of the cables, the mass can be moved over along the whole board.}
                \caption{Planar view of cable-driven robot. This setup contains two motorized pulleys in both top corners. From these two cables a mass is suspended at position $x,y$.
                By changing the length of the cables, the mass is moved over along the whole board.}
                \label{fig:cablebotdrawing}
            \end{figure}
            \begin{marginfigure}
@@ -47,9 +47,8 @@
            It normally consists of two sliders, which behave as a prismatic joint. 
            Because each slider covers a single X or Y axis, the control and dynamics of this system are rather simple.
            The biggest challenge is in the construction of the system, especially when the size of the system is increased.
            The larger system requires bigger length sliders, which are expensive. 
            Another difficulty is the actuation of both horizontal sliders, if these sliders do not operate synchronous, the vertical slider rotates.
            However, the construction of the slider is not able to rotate, resulting in damage to the system.
            The larger system requires longer sliders, which are expensive. 
            Another difficulty is the actuation of both horizontal sliders, if these sliders do not operate synchronous the vertical slider would slant and likely jam.
            \begin{figure}
                \centering
                \includegraphics[width=8.74cm]{graphics/plotter.pdf}
@@ -59,7 +58,7 @@
            
        \subsubsection{Polar-coordinate robot}
            This robot is a combination of a prismatic and a revolute joint.
            Where the revolute joint can rotate the prismatic joint as seen in \autoref{fig:polar}.
            Where the revolute joint can rotate the prismatic joint as shown in \autoref{fig:polar}.
            With this it can reach any point within a radius from the rotational joint.
            This is a little more complex design than the Cartesian robot.
            \begin{figure}
@@ -82,28 +81,47 @@
            Therefore, the complete radius around the revolute joint cannot have any obstacles.
            \autoref{fig:polar_protrude} gives an impression of the required area.
            Even with this area, the arm cannot reach the complete board.
            This makes required space of the setup very inefficient.
            This makes the required space of the setup very inefficient.
            Another disadvantage is that a long arm increases the moment of inertia and the gravitational torque on the joint quadratically.
            Furthermore, the long arm introduces stiffness problems and it amplifies any inaccuracy in the joint.
        
        \subsubsection{SCARA}
            The SCARA robot is a configuration with two linkages that are connected via rotational joints.
            It can be compared to a human arm drawing on a table as seen in \autoref{fig:scara}.
            Similar to the Polar robot it can reach all points within a radius from the base of the robot.
            But the SCARA does not protrude like the polar arm (\autoref{fig:polar_protrude}).
            The \ac{scara} robot is a configuration with two linkages that are connected via rotational joints.
            It compares to a human arm drawing on a table as shown in \autoref{fig:scara}.
            Similar to the polar robot it can reach all points within a radius from the base of the robot.
            But the \ac{scara} does not protrude like the polar arm (\autoref{fig:polar_protrude}).
            Depending on the configuration of the arm, it is possible to keep the arm completely within the area of operation.
            A downside is that the mass of the additional joint and extra arm length increase the moment of inertia and gravitational torque similar to the polar robot.
            This makes the SCARA configuration convenient for small working areas as that keeps the forces managable.
            Additionally, as the arms of the SCARA have a fixed length, it is possible to create a counter balance.
            This makes the \ac{scara} configuration convenient for small working areas as that keeps the forces manageable.
            Additionally, as the arms of the \ac{scara} have a fixed length, it is possible to create a counter balance.
            This can be used to remove any gravitational torque from the system. It would however increase the moment of inertia even further.
            For current specifications, the working area is too large for any practical application of the SCARA.
            For current requirements, the working area is too large for any practical application of the \ac{scara}.
            \begin{figure}
                \centering
                \includegraphics[width=8.74cm]{graphics/scara.pdf}
                \caption{Schematic example of a SCARA, consisting of two rotation linkages. This setup can be compared to a human arm, where the gray base above the whiteboard represents the shoulder and the connections between both linkages the elbow.}
                \caption{Schematic example of a \ac{scara}, consisting of two rotation linkages. This setup can be compared to a human arm, where the gray base above the whiteboard represents the shoulder and the connections between both linkages the elbow.}
                \label{fig:scara}
            \end{figure}

        \subsubsection{Combining}
            A fifth option is to combine two of the discussed configurations, wherein the best properties of two configurations are used.
            The most interesting combination is the cable bot together with the \ac{scara}.
            In this combination, the \ac{scara} is small, only able to write a couple of characters.
            The smaller size of the \ac{scara} makes it quick.
            To write full sentences the \ac{scara} is placed on a carriage that is suspended by the cable bot.
            An example of this \ac{cdc} with the mounted \ac{scara} is shown in \autoref{fig:combined}.
            
            \begin{figure}[h]
                \centering
                \includegraphics[width=10.8cm]{graphics/combined.pdf}
                \caption{Combined system that integrates the cable bot together with the \ac{scara}. The \ac{scara} in red is mounted on the \ac{cdc}.}
                \label{fig:combined}
            \end{figure}

            This increases the complexity of the dynamics of the system, by having four degrees of freedom.
            Furthermore, the movement of the \ac{scara} also causes movement of the \ac{cdc}.
            Shrinking the \ac{scara} also decreases the challenges regarding construction, as long and unstable arms are out of the picture.

        \subsubsection{Choice of system}
            The previous sections have shown four different configurations.
            These configurations are compared in \autoref{tab:initial_design}.
@@ -111,8 +129,8 @@
            \begin{description}
                \item{\emph{Range}}\\
                    The range scores the system on the practical dimension of the system, larger is better.
                    The cable and cartesian configuration scale very well, the cables or slider rails can be made longer without real difficulty.
                    The SCARA or polar configuration run into problems with the arm lengths, as forces scale quadratically with their length.
                    The cable, cartesian, and combined configuration scale very well, the cables or slider rails can be made longer without real difficulty.
                    The \ac{scara} or polar configuration run into problems with the arm lengths, as forces scale quadratically with their length.
                \item{\emph{Speed}}\\
                    Except for the cable bot, all configurations score sufficient on speed.
                    The cable bot can reach high velocities, but the acceleration is limited, depending on the configuration, to the gravitational acceleration.
@@ -121,73 +139,70 @@
                    All systems require DC or stepper motors, but the cartesian setup also requires linear sliders which are expensive, especially for longer distances.
                \item{\emph{Obstruction}}\\
                    The obstruction score depends on the capability of the system to move away from the text on the board, such that the system does not obstruct the written tweet.
                    All systems except for the cable bot can move themself outside of the working area.
                    It is possible that the cables of the cable bot obstruct the view.
                    All systems except for the cable and combined configuration can move themself outside of the working area.
                    It is possible that the wires of the cable or combined configuration obstruct the view.
                    However, the wires are expected to be thin enough to not block any text.
                \item{\emph{Scalability}}\\
                    For the scalability, only the cable bot scores high. 
                    For the scalability, the cable bot and the combined system score high. 
                    The cables make it possible to easily change the operating range of the system, only requiring reconfiguration.
                    The cartesian system scales poor because the length of the sliders is fixed, and longer sliders are expensive.
                    For the Polar system and SCARA, the forces on the joints scale quadratically with the length of the arms.
                    However, the SCARA can be build with counter balance making it scale less worse than the Polar system.
                    For the polar system and \ac{scara}, the forces on the joints scale quadratically with the length of the arms.
                    However, the \ac{scara} can be build with counter balance making it scale less worse than the Polar system.
                \item{\emph{Effective Area}}\\
                    With the effective area, the system is scored on the area it requires to operated versus the writable area.
                    The polar configuration has a low score due to the protruding arm.
                \item{\emph{Interesting Dynamics}}\\
                    The last metric, scores the system on the complexity of the dynamics.
                    This is a more subjective metric, but also a very important one.
                    In the problem description, the complexity of the dynamics was determined as one of the core requirements.
                    The cartesian configuration is trivial, both sliders operate completely separate from each other and the position coordinates can be mapped one to one with the sliders.
                    For the other configuration, some inverse kinematics are required to get from desired position to the control angles of the system.
                    The combined configuration excels for this metric, as it has 4 degrees of freedom and the \ac{scara} movement can cause the carriage to swing.
            \end{description}

            \begin{table}[]
                \caption{Table with comparison of the four proposed configurations and a combined configuration of the cable bot and the SCARA.}
            \begin{table}[h]
                \caption{Table with comparison of the four proposed configurations and a combined configuration of the cable bot and the \ac{scara}.}
                \label{tab:initial_design}
                \begin{tabular}{l|l|l|l|l|l|}
                    \cline{2-6}
                    & Cable bot & Cartesian & Polar & SCARA & Combined \\ \hline
                    \multicolumn{1}{|l|}{Range}                                                          & + +      & +         & - -   & -     & + +      \\ \hline
                    \multicolumn{1}{|l|}{Speed}                                                          & -        & +         & +     & + +   & +        \\ \hline
                    \multicolumn{1}{|l|}{Cost}                                                           & + +      & - -       & +     & +     & +        \\ \hline
                    \multicolumn{1}{|l|}{Obstruction}                                                    & -        & +         & +     & +     & -        \\ \hline
                    \multicolumn{1}{|l|}{Scalability}                                                    & + +      & -         & - -   & -     & +        \\ \hline
                    \multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Effective\\ area\end{tabular}}       & + +      & +         & - -   & +     & + +      \\ \hline
                    \multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Interesting\\ dynamics\end{tabular}} & -        & - -       & -     & +     & + +      \\ \hline
                \rowcolors{2}{lightgray}{white!100}
                \begin{tabular}{l c c c c c }
                    \toprule
                    & Cable bot & Cartesian & Polar & \ac{scara} & Combined \\
                    \midrule
                    \multicolumn{1}{l}{Range}                                                          & $+ +$      & $+  $       & $- -$   & $-  $   & $+ +$      \\ 
                    \multicolumn{1}{l}{Speed}                                                          & $-  $      & $+  $       & $+  $   & $+ +$   & $+  $      \\ 
                    \multicolumn{1}{l}{Cost}                                                           & $+ +$      & $- -$       & $+  $   & $+  $   & $+  $      \\ 
                    \multicolumn{1}{l}{Obstruction}                                                    & $-  $      & $+  $       & $+  $   & $+  $   & $-  $      \\ 
                    \multicolumn{1}{l}{Scalability}                                                    & $+ +$      & $-  $       & $- -$   & $-  $   & $+  $      \\ 
                    \multicolumn{1}{l}{\begin{tabular}[c]{@{}l@{}}Effective\\ area\end{tabular}}       & $+ +$      & $+  $       & $- -$   & $+  $   & $+ +$      \\ 
                    \multicolumn{1}{l}{\begin{tabular}[c]{@{}l@{}}Interesting\\ dynamics\end{tabular}} & $-  $      & $- -$       & $-  $   & $+  $   & $+ +$      \\ 
                    \midrule
                    \hiderowcolors
                    \multicolumn{1}{l}{Total} & \multicolumn{1}{r}{$ +5$} & \multicolumn{1}{r}{$ -1$} & \multicolumn{1}{r}{$ -4$} & \multicolumn{1}{r}{$ +4$} & \multicolumn{1}{r}{$ +8$} \\
                    \bottomrule
                \end{tabular}
            \end{table}           
            
            Based on this comparison, I disqualified the cartesian and polar system.
            The cartesian has no interesting dynamics and is expensive to build at the current scale.
            The polar system is just not feasible, the arm length required to cover the writing area results forces that are too large.
            Making a rotational joint that delivers the torque and velocity required for such an arm, is just out of the scope of this case study.
            The two remaining configurations come with serious downsides as well.
            The cable bot is slow, and the arm length for the SCARA is also likely to cause problems.
            However, by combining both, it is possible to get a system that fits the requirements very well.
            By building a small SCARA that is the suspended by the cable bot, it combines the best of both worlds.
            The small SCARA is quick and accurate, while the cable bot gives the system an enormous range.
            Resulting in a system that scores high on all criteria except obstruction.
            The grading for the combined system is shown in the most right column in \autoref{tab:initial_design}.

            \begin{figure}
                \centering
                \includegraphics[width=10.8cm]{graphics/combined.pdf}
                \caption{Combined system that integrates the cable bot together with the SCARA. The SCARA in red is mounted on the carriage. This carriage is then suspended by cables.}
                \label{fig:combined}
            \end{figure}
            In the combined system, the SCARA will only be large enough to write a small number of characters at the time.
            This will alternate with the cable bot moving the base of the SCARA to the next position, so that it can write the next set of characters on the whiteboard.
            \autoref{fig:combined} shows a simple view of the system.
            The comparison in \autoref{tab:initial_design} shows that the combined configuration as preferred.
            Which is not surprising as it combines the advantages of both the cable bot and \ac{scara}.
            Although those systems have a good score of their own, they have disadvantages.
            The cable bot has low acceleration and no challenging dynamics.
            The main difficulty for the \ac{scara} is being able to build it large enough.

            The combined configurations, complement each other.
            The range of the \ac{cdc} allows for a small \ac{scara}.
            The small size of the \ac{scara} makes it quick.
            This compensates for the low acceleration of the cable bot and removes the need for a \ac{scara} with long arms.
            Therefore, the choice of configuration is the combined system of the \ac{scara} and \ac{cdc}.
            
        \subsubsection{Evaluation}
            This was the first step that felt really productive in the design process.
            It created a enormous amount of information and insight of the design.
            In hind sight, it would have been useful to have this information during the specifications step.
            However, as the specifications step are mainly on the "what" to solve, and specifically not on "how" to solve it, this information was avoided on purpose during the specifications step.
            In hind sight, it would have been useful to have this information during the requirements step.
            However, as the requirements step are mainly on the "what" to solve, and specifically not on "how" to solve it, this information was avoided on purpose during the requirements step.

            This step did result in an initial design that can be used in the next steps.
            This step did result in an initial design that is used in the next steps.
            However, I noticed that none of the previous steps have a clear start or end.
            For the problem description and the specification steps the question is when all required information is collected.
            For the problem description and the requirements steps the question is when all required information is collected.
            In the initial design it is always possible continue researching design options to come up with an even better design.
            Especially with complex system, it is unrealistic to create complete specifications before making design decissions.
            Especially with complex system, it is unrealistic to create complete requirements before making design decisions.
            Resulting in the question: at what point do we have enough information and must we move to the next design step?
            This is also known as the \emph{requirement versus design paradox} \autocite{fitzgerald_collaborative_2014}.
--- a/content/case_experiment_problem_description.tex
+++ b/content/case_experiment_problem_description.tex
@@ -2,7 +2,8 @@
 \subsection{Problem Description}
 The problem description describes the need for a solution or system.
 In this case, I want a robot that can write a tweet on a whiteboard.
 A specific requirement is that the system must be complex enough, such that it uses sufficient aspects of the design method to be able to evaluate that design method.
 A specific requirement is that the system must be complex enough, such that the specific aspects of the design method are used.
 These specific aspects are the ones that deal with complexity and are subject to the evaluation.
 The system must meet the following requirements:
 \begin{itemize}
    \item Write a twitter message, or tweet, on a whiteboard.
@@ -18,5 +19,5 @@ As most of the work for the problem description was already done by choosing the
 However, it was not expected to be this minimal.
 Perhaps the most serious disadvantage is the absence of stakeholders.
 Normally, a good problem definition focusses on getting the stakeholders on the same line \autocite{shafaat_exploring_2015}.
 However, this case study does only have one stakeholder, the author, defeating the purpose getting everyone on the same line.
 However, this case study does only have one stakeholder, the author, defeating the purpose of getting everyone on the same line.
 Creating a more elaborate problem description would not improve the evaluation of the design process, but it does cost valuable time.
--- a/content/case_experiment_prototype.tex
+++ b/content/case_experiment_prototype.tex
@@ -1,49 +1,62 @@
 %&tex
 To validate the dynamical and mechanical models, I will build a prototype of the current design.
 To validate the dynamical and mechanical models, I have build a prototype of the current design.
 For the mechanical design, the CAD model is used to print the custom parts.
 Other components, such as steppers, microcontroller, screws and miscellaneous electronics, are ordered.
 To test the dynamics, the steppers and servo have to be actuated.
 To achieve this actuation a control law is written in software.
 To achieve this actuation a control law has been written in software.

 \subsection{Mechanical Construction}
 With the 3D printed parts the SCARA was easy to construct.
 The diameter of the holes in the parts were printed slightly undersized.
 This was on purpose, such that the holes can be drilled to the specified size.
 With the 3D printed parts the \ac{scara} was easy to construct.
 To connect the bodies on the joints, a bolt with washers is used.
 Although this is clearly not the ideal technique to build joints, it was by far the easiest option.
 Although this is clearly not the ideal technique to build joints, it sufficed and was by far the easiest option.

 During assembly I noticed that the bolts of a joint and those that hold the stepper motor in place collided.
 This was possible because the bolts were not included in the CAD-model.
 In hindsight this should have been included.
 Fortunately there was enough clearance to mount the SCARA slightly further on the axle.
 Resulting in an operating SCARA without having to redesign the mechanics.
 Fortunately there was enough clearance to mount the \ac{scara} slightly further on the axle.
 Resulting in an operating \ac{scara} without having to redesign the mechanics.

 \subsection{Control of the SCARA}
 \subsection{Control of the \ac{scara}}
 Although the focus of the design plan was specifically not the software, it still forms an important part of the development.
 To run the software, I chose for a STM32 \ac{mcu}, which is a powerful processor with sufficient IO available.
 The servo motor is directly connected to the IO of the \ac{mcu} while the stepper motor is connected via a stepper driver board\footnote{IC with H-bridges to power the stepper motor.}, see \autoref{fig:signals}.
 RIOT-OS was chosen as an operating system due to prior experience and available support.
 To write characters on the board the following tasks are implemented in software:
 \begin{itemize}
    \item Software driver for the stepper controller
    \item Software driver for servo motor
    \item Inverse Kinematics Function
    \item Control/Path planning
 \end{itemize}
 \begin{marginfigure}
    \centering
    \includegraphics[width=5cm]{graphics/electronics.pdf}
    \caption{Hardware connections. The servo motor connected to a pwm-output. The stepper controller connected via UART and IO-pins. The stepper controller provides the correct current for the stepper motors.}
    \caption{Hardware connections. The servo motor connected to an IO-output. The stepper controller connected via UART and IO-pins. The stepper controller provides the correct current for the stepper motors.}
    \label{fig:signals}
 \end{marginfigure}
 Although the focus of the design plan was specifically not the software, it still forms a important part of the development.
 To run the hardware, I chose for for a STM32 \ac{mcu}. This is a powerfull processor with sufficient IO available.
 The servo motor is directly connected to the IO of the \ac{mcu} while the stepper motor is connected via a stepper controller board, see \autoref{fig:signals}.
 RIOT-OS was chosen as an operating system due to prior experience and available support.
 To be able to write characters on the board the following tasks have to be implemented in software:
 \begin{itemize}
    \item Driver for the stepper controller
    \item Driver for servo motor
    \item Inverse Kinematics
    \item Control/Path planning
 \end{itemize}

 The stepper controller chip can be configured over UART and has two simple IO pins for step and direction signal.
 To simplify the control, the software driver configures the stepper controller and includes functions to move the stepper motor to a certain angle.
 Meaning that the feedforward control of the steppers is handled by the software driver class.
 The angle of the servo motor is controlled by the pulse length of a square wave.
 This signal is generated in the IO peripherals as a PWM signal. 
 The software driver has a toggle function that changes the pulse length. Making the maker lift from or lower on the board.
 The code for the servo driver was already available as a module in RIOT-OS.
 The task of the software driver is to handle the communication to the hardware stepper drivers.
 At initialisation of the software, the hardware stepper driver is configured over hardware.
 When a new set-point is set in the software driver, the time between each step is calculated.
 The software driver creates a time-out event with a callback that sends a step signal to the hardware stepper driver.
 The use of time-out events make it possible to run multiple stepper drivers in software asynchronous.

 The set-point for the software driver is calculated by interpolating the path between the current position and the desired position.
 This interpolation is necessary to draw a straight line between two points with the \ac{scara}, as a linear movement of the angle would create curved paths.
 Because the software stepper driver counts the steps send to the stepper motor, which gives the current position of the \ac{scara}.
 The calculation and update of the next set-point is done with a fixed interval.
 To calculate the angles that are needed for the set-points a lookup table is used, which replaces expensive trigonometric calculation needed for inverse kinematics.
 An advantage of this approach is that it can cope with missed or late event callbacks for the software stepper driver.

 The path planning is responsible for the desired position.
 This can be a rectangle or a set of three characters.
 The font for the characters is made by \textcite{hudson_asteroids_2015} and consists of a header file with an array of coordinates for each character.
 When the current position of the \ac{scara} is within range of the desired position, the desired position is updated with the next coordinate of the character.

 There are two special elements in the array of coordinates: up and down.
 These specify whether the marker should be lifted from or lowered on the board.
 In the transition period of lifting or lowering, there is a short builtin wait for the stepper movement, to avoid unwanted drawing.
 When the marker is lifted, the interpolation is disabled and the stepper drivers move directly to the position where the next line starts.
 \begin{marginfigure}
    \centering
    \includegraphics[width=2.83cm]{graphics/code_objects.pdf}
@@ -51,21 +64,16 @@ The code for the servo driver was already available as a module in RIOT-OS.
    \label{fig:objects}
 \end{marginfigure}

 The path planning is able to write three characters with the SCARA.
 The font for the characters is made by \textcite{hudson_asteroids_2015}.
 This font consists of a simple coordinates for characters and is written in C.
 The path planning is updated with a fixed interval.
 During the update, the set point is linearly interpolated, otherwise the lines are curved between set points.
 To get the angle set points for the stepper motors, the $x,y$-coordinate set point is converted using the inverse kinematics.
 The inverse kinematics is analogous to the model that is used in the development cycle of the SCARA.
 The angle set points are updated for the stepper driver.
 The data path is shown in \autoref{fig:objects}.
 For the lifting of the marker the servo on the arm is used.
 The angle of the servo motor is controlled by the pulse length of a square wave.
 The software servo driver switches the pulse length when it is ordered to lift or lower the marker.
 The code for the servo driver is a provide module in RIOT-OS.

 In summary, the path planning uses the coordinates of the characters to determine the next desired position and the state of the marker.
 When a line must be drawn the marker is lowered and the path to the end of the line is interpolated.
 The position from the interpolation is then converted to angles using the look-up table.
 The angles are pushed to the software stepper driver, which are used to calculate the interval between steps.
 The data path for drawing a line is shown in \autoref{fig:objects}.

 The stepper driver has a feedforward controller.
 The driver limits the acceleration and speed to keep the motor within operating specifications and keeps track of the current status of the stepper motor.
 When the angle set point is updated, the driver calculates the time interval between each step and sets a hardware timer to that interval.
 This allows the controller and other drivers to be executed between each step.
 This approach works only if the code executes fast enough.
 During the testing, I found that the inverse kinematics calculation was too expensive, even with the integrated floating point unit.
 As the \ac{mcu} has sufficient flash storage available, the inverse kinematics calculation is replaced by a lookup table.
 \input{content/case_evaluation_result.tex}

--- a/content/case_experiment_scara.tex
+++ b/content/case_experiment_scara.tex
@@ -7,18 +7,21 @@
        The implementation of the end-effector proved to be unfeasible and was therefore removed from the design.
        This means that only two features are left.
        \autoref{tab:featurestab2} shows an updated feature comparison.
        Compared with the previous feature selection in \autoref{tab:firstfeatureselection}, the number of tests for the \ac{scara} decreased and the Risk/Time increased.
        Compared with the previous feature selection in \autoref{tab:firstfeatureselection}, the number of tests for the \ac{scara} decreased and the \ac{cof}/Time increased.
        This is because \autoref{test_tool_change} relied on both the \ac{scara} and the End-effector which is no longer applicable.
        Based on the feature comparison, the next component to implement is the \ac{scara}.

        \begin{table}[]
        \begin{table}[h]
            \caption{Comparison of the two remaining features in the design process. This table is an updated version of \autoref{tab:firstfeatureselection}.}
            \label{tab:featurestab2}
            \begin{tabular}{|l|l|l|l|l|l|}
                \hline
                Feature      & Dependees   & Tests  & Risk   & Time    & Risk/Time  \\ \hline
                \ac{scara}        & -           & 2      & 50\%   & 12 days & 4.2        \\ \hline
                \ac{cdc}     & -           & 2      & 30\%   & 10 days & 3          \\ \hline
            \rowcolors{2}{white!100}{lightgray}
            \begin{tabular}{llrrrr}
                \toprule
                Feature      & Dependees   & Tests  & \ac{cof}   & \multicolumn{1}{l}{Time}    & \ac{cof}/Time  \\ 
                \midrule
                \ac{scara}        & $-$           & $2$      & $50\%$   & $12$ days & $4.2$        \\
                \ac{cdc}          & $-$           & $2$      & $30\%$   & $10$ days & $3$          \\ 
                \bottomrule
            \end{tabular}
        \end{table}

@@ -26,7 +29,8 @@
            The feature selection for the second cycle is an updated selection process of the first cycle (\autoref{sec:case_feature_selection_1}).
            This resulted in a quick and effortless feature selection process, as most of the work was already done.

    \subsection{Rapid Development for SCARA}
    \subsection{Rapid Development for \acs{scara}}
        \label{sec:rdfs}
        The goal is to present a functional model of the \ac{scara}.
        The requirements state that it must be able to write three characters within two seconds.
        And to pass \autoref{test1} it must draw a \SI{50}{\milli\meter} by \SI{70}{\milli\meter} rectangle within one second.
@@ -34,33 +38,33 @@
        For the lowest detail level of the design, I decided on a kinematics model.
        The model is very simple as it does not implement any physics.
        However, the model enables me to tinker with the design parameters, such as the lengths of the linkages and joint angles.
        In the following steps, the level of detail is gradually increased to arrive at a competent model.
        In the following steps, the level of detail is gradually increased to arrive at an elaborate model.
        Planning all the different steps in advance is difficult as design decisions still need to be made.
        Nonetheless, I can describe at least the following levels of detail for the model:
        \begin{enumerate}
            \item Basic kinematics model, no physics.
            \item Basic physics model, ideal 2D physics.
            \item Basic Motor behavior, 2D physics with non-ideal DC-motor.
            \item Basic control law, path planning.
            \item \textbf{Basic kinematics model:} forward and inverse kinematics, no physical behavior.
            \item \textbf{Basic physics model:} ideal 2D physics, ideal joints and rigid bodies with mass and inertia.
            \item \textbf{Basic motor behavior:} joint actuation with non-ideal DC motor.
            \item \textbf{Basic control law:} path planning.
        \end{enumerate}
        After these steps the optimal order of implementation for the levels of detail becomes vague.
        However, the following elements are required to make a competent model:
        However, the following elements are required to make an elaborate model:
        \begin{itemize}
            \item Improved motor model
            \item 3D physics model
        \end{itemize}
        When the first design decisions made, the succeeding levels of detail for these and other elements are laid out.
        When the first design decisions are made, the succeeding levels of detail for these and other elements are laid out.


        \subsubsection{Evaluation}
            The current steps in the rapid development are difficult to perform.
            There is, unsurprisingly, lack of a clear vision of the end-product.
            Which makes an explicit description of every level of detail not realistic.
            However, it was still possible to describe the initial steps in the level of detail of the design.
            There is, unsurprisingly, lack of a clear vision of the end-product, which makes an explicit description of every level of detail not realistic.
            However, it was still possible to describe steps for the initial levels of detail in the design.

            The remaining elements, that are essential to the design, take shape in a later stage of the development.
            Apart from this small deviation, the deliverables of this step are a good start of this development cycle.

    \subsection{Variable Detail Approach}
    \subsection{Variable-Detail Approach}
        The following steps is to increase the level of detail of the model.
        The initial model together with the set of steps in the detail level is inherited from the previous design step.
        To start, I implement the basic model and implement the different levels of detail.
@@ -68,7 +72,7 @@
        The decisions make it possible to plan the subsequent levels of detail.
        Implementing these details results in a competent model.

        \subsubsection{Basic Kinematics Model}
        \subsubsection{Basic Design Implementation}
            \begin{marginfigure}
                    \centering
                    \includegraphics[width=0.9\linewidth]{graphics/scara_arm_kinematics.pdf}
@@ -81,13 +85,13 @@
            I tested if the \ac{scara} reaches the required operating area, to satisfy system requirement 14.
            The operating area is a couple of centimeters away from the base of the \ac{scara}.
            This is to avoid the singularity point that lies at the base of the \ac{scara}.
            Resulting in longer arms than strictly necessary but reducing the operating angles of the joints, allowing for simpler construction.
            Resulting in the arms being longer than strictly necessary but it reduces the operating range for the angles of the joints, allowing for simpler construction.
            
            At this point, there are already multiple design decisions made about the position of the operating area and the arm lengths.
            As second detail iteration the basic physics of the model are implemented.
            The model is in the form of a double pendulum, with two actuated joints.
            The ideal motors in the joints made give the \ac{scara} unlimited acceleration.
            As the one of the goals is to get an indication on what the required torque for these joints is, the ideal motors are replaced with basic DC-motors.
            The ideal motors in the joints give the \ac{scara} unlimited acceleration.
            Replacing the ideal motors with a DC-motor gives an indication about the torque required for operation.
            Implementing a simple PID-controller allows the \ac{scara} to follow the rectangular path as described in \autoref{test1}.
            The simulation allowed me to determine the minimum requirements of the motors.
            The motors must be able to deliver at least \SI{0.2}{\newton\meter} of torque and reach an angular velocity of at least \SI{12}{\radian\per\second}.
@@ -97,13 +101,14 @@
            However, the current configuration is very simple but requires a motor in the joint.
            In \autoref{fig:scaradesign}, this setup is shown as configuration 1.
            The disadvantage is that a motorized joint is heavy, which has to be accelerated with the rest of the arm.

            Other configurations in \autoref{fig:scaradesign} move the motor to a static position.
            Configuration 2 is a double arm setup, but has quite limited operating range, caused by a singularity region in the system when both arms at the top are in line with each other.
            Configuration 2 is a double arm setup, but has a limited operating range, caused by a singularity region in the system when both arms at the top are in line with each other.
            Configuration 3 also has such a singularity, but due to the extended top arm this point of singularity is located outside of the operating range.
            However, this configuration requires one axis with two motorized joints on it.
            Even though this is possible, it does increase the complexity of the construction.
            By adding an extra linkage, the actuation is split as shown in configuration 4.
            Configuration 4 is the preferred option for the \ac{scara}
            Configuration 4 is the preferred option for the \ac{scara}.
            \begin{figure}
                \centering
                \includegraphics[width=0.875\linewidth]{graphics/scara_design.pdf}
@@ -111,30 +116,38 @@
                \label{fig:scaradesign}
            \end{figure}

            The actuation of the arm is done with stepper motors, which have a strong advantage over DC-motors with their holding torque.
            The holding torque removes the need for a feedback controller that compensates for external forces.
            Allowing the stepper motors to be fully operated with a feedforward controller.
            However, they are heavier and more expensive but the additional mass is beneficial as increased inertia of the base.
            The extra inertia reduces the displacement which is caused by the reaction force of the \ac{scara} accelerating.
            The extra costs are easily compensated as it saves development time due to the simplified control law, and the removed need for extra angle sensors used in feedback control.
            The current implementation with DC-motors require a feedback controller that compensates for external forces.
            Such feedback control requires a position sensor for each motor.
            A simpler solution is to use stepper motors instead.
            The advantage of a stepper motor is that it is designed to maintain a specific angle.
            The stepper motors make it possible to use a feedforward controller.
            This removes the need for a position sensor.
            
            The stepper motors are havier than the DC-motors
            However, as the new configuration places the motors on the \ac{cdc}, the additional mass is benificial.
            The rapid movement of the \ac{scara} creates a reaction force on the \ac{cdc}.
            With a heavier \ac{cdc}, the reaction force results in less movement of the \ac{cdc}

            Unfortunately, the stepper motors are more expensive than simple DC-motors.
            Nonetheless, the extra costs are easily compensated as it saves development time due to the simplified control law, and the removed need for extra angle sensors used in feedback control.

            Due to the aborted implementation of the end-effector, the \ac{scara} must also lift the marker of the board.
            With the fourth configuration (\autoref{fig:scaradesign}), it is possible to add an extra joint in the linkage.
            As the marker only needs to be moved a couple of millimeters from the board, a simple hobby servo suffices.

        \subsubsection{Advanced Detail Design}
        \subsubsection{Advanced Detail Implementation}
            The design decisions made in the previous sections, make it possible to plan the next steps of adding detail.
            The following steps are an addition to the steps as described in the previous section:
            The following steps are an addition to the steps as described in \autoref{sec:rdfs}:
            \begin{enumerate}
                \setcounter{enumi}{4}
                \item Stepper motor behavior.
                \item Updating physics model to 3D physics.
                \item Marker lifting behavior, servo lifts marker of the board.
                \item \textbf{Advanced motor behavior:} Stepper motor behavior.
                \item \textbf{Advanced physics model:} Updating physics model to 3D physics.
                \item \textbf{Advanced marker lifting:} Marker lifting behavior, servo lifts marker of the board.
            \end{enumerate}
            Starting by replacing the DC-motor with a stepper motor model, which is based on a model by \textcite{karadeniz_modelling_2018}.
            The controller is updated as well, to accommodate for the behavior of the steppers.
            The next step is to implement a dynamic model of configuration 4 in \autoref{fig:scaradesign}.
            The dynamics of the \ac{scara} are based on a serial link structure \autocite{dresscher_modeling_2010}.
            The dynamics of the \ac{scara} are based on a serial link structure \autocite{stramigioli_geometry_2001}.
            This serial link structure makes it easy to add and extend joints, bodies and mass points to the system.
            Therefore, the last detail, the marker lifting, was added without any difficulty.
            The servo is connected via a linkage with the marker such that it rotates away from the board.
@@ -143,12 +156,15 @@
            At this point the development has reached a detailed design together with a dynamic model representing that design.
            The dynamic model is a useful tool to test and evaluate the system behavior.
            However, it does not include the shapes of the components and can therefore not be used to evaluate clearance or collision between components.

            By implementing the design using CAD software, it is possible to inspect for collisions.
            Furthermore, this model is than also used to print the custom parts.
            Furthermore, this model is then also used to print the custom parts.
            For the mechanical part I used OpenSCAD as CAD software, based on prior experience with the software.
            With this it was possible to implement all the custom components as well as the \ac{ots}-components.
            Using the inverse kinematics model from the basic design of the \ac{scara}, the angles were directly applied on the components in system.
            Allowing me to change the configuration of the \ac{scara} and inspect the clearance between each component.
            To inspect how the components moved, the inverse kinematics model is implemented in the CAD drawing as well.
            The inverse kinematics made it possible to insert cartesian coordinates, resulting in a dynamic CAD design.
            Using different orientations of the end-effector allowed me to inspect the clearance between the different components.

            Following the rectangular path as defined in \autoref{test1} revealed that collisions occurred between parts.
            These collisions were resolved by adding an indentation in one linkage and moving another linkage.
            These changes are shown in \autoref{fig:scad_clearance}
@@ -157,7 +173,7 @@
                \centering
                \includegraphics[width=0.8\linewidth]{graphics/scad_scara_circles.png}
                \caption{
                    CAD of the \ac{scara} configuration, with the end-effector orientated in the lower left corner of the operating area. 
                    CAD of the \ac{scara} configuration, with the end-effector oriented in the lower left corner of the operating area. 
                    The configuration has been adapted at the two circled points, to resolve collisions in this orientation. 
                    An indentation was made to ensure that the arm can make the required angle.
                    The bottom linkage was located above the joints as depicted in the fourth configuration in \autoref{fig:scaradesign}.
@@ -180,19 +196,21 @@
            Prior to the design, it was possible to plan 4 levels of detail.
            After implementing these levels of detail, the design decisions taken made it possible to define additional levels of detail.

            In total there are seven predefined levels of detail in the design.
            Meaning that there must also be seven test cycles.
            However, I noticed that this number was significantly higher.
            In total there are seven predefined levels of detail in the design, meaning that there must also be seven test cycles.
            However, I noticed that testing occurred more often than seven times.
            During the design, running the simulation of the dynamics is easy.
            Resulting in extremely short feedback loops, sometimes even minutes.
            For example, changing the arm lengths and evaluate the new behavior.
            Did it improve? Is this as expected?
            Implicitly, the system was very often tested and changed based on test results.

    \subsection{Conclusion}
        With the development of the \ac{scara} completed.
        Following the design plan, the development has to be repeated for the design of the \ac{cdc}.
            These small intermediate tests were often implicitly created and are not the tests as specified in the test protocol (\label{app:test_specification}).
            Nonetheless, they provide insight that is valuable for the design process.
            The interesting question here is whether these small tests should be part of the design process and what it would add to the design process.

    \subsection{Conclusion of Development}
        At this point, the development of the \ac{scara} is completed.
        According to the design plan, the next step for the development is the implementation of the \ac{cdc} feature.
        However, the evaluation of the development until this point resulted in enough information to draw conclusions about the design plan.
        I expect that executing this development a third time is not beneficial to the case study, given the additional effort.
        Time is better spent on the realization of a prototype and improving the current design method.
        Time is better spent on the realization of a prototype and evaluating the current design method.
        Therefore, the next section goes into the construction of the prototype instead of the development of the \ac{cdc}.
--- a/content/case_experiment_specifications.tex
+++ b/content/case_experiment_specifications.tex
@@ -1,25 +1,24 @@
 %&tex
    \subsection{Specifications}
    \subsection{Requirements}
    \label{sec:specifications}
        The next step is to create specifications based on the problem description.
        The goal is to write and remove a tweet on the whiteboard.
        The next step is to create requirements based on the problem description.
        The goal is to write and erase a tweet on the whiteboard.
        Originally a tweet had a character limit of 140, but this was doubled to 280\autocite{rosen_tweeting_2017}.
        However, the decision is made to keep the limit at 140, as it does not improve the case study but can increase the construction cost.
        The text is limited to fifty characters per line, with a total of three lines.
        This results in ten extra characters that are used for word wrapping.
        For the readability, the distance to a whiteboard in a meeting room is taken as \SI{4}{\meter}.
        For the readability, the distance to a whiteboard in a meeting room is taken as four meters.
        The operating speed must allow the tweet to be written within three minutes. 
        Therefore, the goal is to write one character per second.
        The last requirement is that the dynamics of the system must be sophisticated.
        Meaning that a solution with complex or non-trivial behavior is preferred.
        Using \ac{ears} to define these specifications gives:
        Using \ac{ears} to define these requirements gives:
        \begin{specification}
            \begin{enumerate}
                \setlength{\itemsep}{10pt}
                    \input{content/input/speclista.tex}
        \end{enumerate}
        \end{specification}
        Some other specifications that are related to the operation of the system are:
        Some other requirements that are related to the operation of the system are:
        \begin{specification}
            \begin{enumerate}
                \setcounter{enumi}{8}
@@ -48,12 +47,12 @@
            \end{itemize}
        \end{specification}
        \subsubsection{Evaluation}
            The specifications step was performed without problems.
            Defining the specifications for the problem description did not present any difficulty.
            Due to the simplicity of the problem description, there were no contradictory requirements, which would complicate the specifications.
            The requirements step was performed without problems.
            Defining the requirements for the problem description did not present any difficulty.
            Due to the simplicity of the problem description, there were no contradictory requirements, which would complicate the requirements step.
            Furthermore, a single stakeholder takes away any negotiation between stakeholders.
            Where the stakeholders are a combination of engineers on the design team and/or the project client.

            Although the specifications itself are not difficult to define, ensuring that they are complete is difficult.
            Team members and stakeholders help to spot any ambiguity or problems with the validity.
            Although the requirements itself are not difficult to define, ensuring that they are complete is difficult.
            Discussion between team members and stakeholders helps to spot any ambiguity or problems with the validity.
            \ac{ears} was very useful in this case as it gives a strong template to help avoid ambiguity.
--- a/content/case_experiment_test_protocol.tex
+++ b/content/case_experiment_test_protocol.tex
@@ -3,21 +3,23 @@
 \label{sec:test_protocol}
    The last step of the preparation phase is to implement a test protocol.
    The tests are designed to validate if the system meets its requirements.

    While defining the tests, it became clear that part of the requirements was not sufficiently defined.
    The current requirements apply to the complete system and is not updated for the design choices made in the initial design.
    If the tests are made based on the current requirements, they can only be performed when the complete design is implemented.
    To create tests that apply to specific features or compoments, the requirements had to be updated.
    This update adds order of operations and additional requirements and is explained in the following two sections.
    This update adds order of operations and additional requirements, which are explained in the following two sections.
    The third section explains how the tests are formed based on the up-to-date requirements.
    
    %%% Reviewed tot hier.

    \subsubsection{Defining the Order of Operation}
    There are two modes of operation: writing and erasing.
    Defining the order of operation also distributes the responsibility between the different components.
    The writing operation consists of performing the following steps:
    In these situations, the end-effector holds a writing or erasing tool respectively.
    By defining the order of operation for each mode, specific requirements are assigned to the \ac{scara} and the \ac{cdc}.

    The current design uses the \ac{scara} to write characters on the board at a static position.
    When these characters are written the \ac{cdc} moves to the next position:
    \begin{order}{Writing}
        \emph{Precondition:} Marker as tool in end-effector.
        \emph{Precondition:} Board marker as tool in end-effector.
        \begin{enumerate}
            \item Move \ac{cdc} to position of characters.
            \item Write three characters with the \ac{scara}.
@@ -26,10 +28,11 @@
        \end{enumerate}
    \end{order}


    The second order of operation is about the erasing.
    Removing text from the board is done by the following steps:
    \begin{order}{Erasing}
        \emph{Precondition:} Wiper as tool in end-effector.
        \emph{Precondition:} Board eraser as tool in end-effector.
        \begin{enumerate}
            \item Move \ac{cdc} to position of characters.
            \item Clear the area in reach of the \ac{scara}.
@@ -37,13 +40,18 @@
        \end{enumerate}
    \end{order}

    A possible third order of operation can be defined for tool switching.
    This order of operation depends on how end-effector grabs and releases the tools.
    A possible third order of operation is tool switching using the end-effector.
    At this point, the design of the end-effector is not definitive enough to determine an order of operation.
    Additionally, not having an order of operation for the end-effector did not hinder the definition of tests.

    \subsubsection{Improving Requirements}
    Based on the order of operations, the following requirements were added to the lists in \autoref{sec:specifications}:
    The defined order of operations add more requirements to the system.
    Two of the new requirements specify the operational behavior of the \ac{scara} and \ac{cdc}, based on the order specified above.
    To ensure that the overall system can still write one character per second, the \ac{scara} and \ac{cdc} must both complete their task in three seconds.
    Therefore, two seconds are assigned to the \ac{scara} to write three characters and the \ac{cdc} gets one second to move the \ac{scara} to the new position.

    A fifth requirement is added because it was overlooked during the previous steps.
    The five system requirements are in addition to those in \autoref{sec:specifications}:
    \begin{specification}
        \begin{enumerate}
            \setcounter{enumi}{12}
@@ -51,10 +59,10 @@
        \end{enumerate}
    \end{specification}
    These additional requirements take into account that the current design consists of a \ac{scara}, end-effector and \ac{cdc}.
    Where each of these components have a different role and thus a different responsibility in the system.
    Where each of these components has a different role and thus a different responsibility in the system.

    \subsubsection{Setting up the tests}
    Using the updated requirements, set of test cases is created.
    Based on the updated requirements, a set of test cases is created.
    In total there are five small and five large test cases.
    The small tests cover a single compoment or feature and the large tests combine multiple features.
    Each test specifies for which requirements they apply and include a description that explains the test.
@@ -75,7 +83,7 @@

    \subsubsection{Evaluation}
        This step was completed without many difficulties.
        Which includes the revision of the earlier requirements and definition of orders of operation.
        Eventhough this step included an unexpected revision of the earlier requirements and definition of order of operations.
        Indicating that I overlooked details while defining the requirements in \autoref{sec:specifications}.
        According to the design plan as described in \autoref{chap:analysis}, I have to go back and review those requirements.
        Followed by reviewing all steps after the requirements.
--- a/content/case_method.tex
+++ b/content/case_method.tex
@@ -5,8 +5,8 @@ The goal of this case study is to evaluate the design plan as presented in the p
 The evaluation is done by developing a system according to the design plan.
 In general, the method of the case study follows all the steps of the design plan.
 Additionally, an evaluation protocol ensures that the development is evaluated consistently.
 The last important thing is a subject of design that is developed in the case study.
 The next sections present the evaluation protocol and the subject of design.
 The last important thing is a subject of design that is developed as the case study.
 The next sections present the evaluation protocol and explains the choice for subject of design.

 \section{Evaluation Protocol}
 \label{sec:evaluation_protocol}
@@ -21,8 +21,8 @@ The next sections present the evaluation protocol and the subject of design.
        The questionnaire consists of two sets of questions.
        The first set of questions is shown in \autoref{tab:prepost}.
        This set consists of pairs of questions and focusses specifically on the execution of the design step.
        Each pair embodies a theme, with one questions answered before, and the other question answered after the execution of the design step.
        The goal of these pairs is to record the expected and planned execution with the results of the execution.
        Each pair embodies a theme, with one question answered before, and the other question answered after the execution of the design step.
        The goal of these pairs is to compare the expected and resulting outcome of the design step.
        The second set of questions focusses on the described method of the design step.
        These questions are shown in \autoref{tab:questionsmethod}.

@@ -37,7 +37,7 @@ The next sections present the evaluation protocol and the subject of design.
            \vspace{1mm} \large{Prestep}  & \vspace{1mm} \large{Poststep} \\
            Questions prior to the execution of the step to set a baseline. & Questions after the execution of the step to check if the implementation met the expectations. In hind-sight, what should have been executed differently?\\
            \hline 
            \textbf{What was the previous step?} & \textbf{What will be the next step?} \\
            \textbf{What was the previous step?} & \textbf{What is the next step?} \\
            Does this influence this step? Is this a review? & Moving forward or is a review required of previous step(s)? \\
            \hline
            \textbf{Describe the plan of action.} & \textbf{Explain any deviations from the plan of action.} \\
@@ -47,7 +47,7 @@ The next sections present the evaluation protocol and the subject of design.
            What is the protocol to review the result of this step? & How was the evaluation done? Did it reveal something new? \\
            \hline
            \textbf{What is the expected workload?} & \textbf{Was the workload different than expected?} \\
            How many hours are required for the execution of the step? Also give a range in your uncertainty. & How much time was invested in the step? Why was it more or less than expected? \\
            How many hours are required for the execution of the step? Also give a range in your uncertainty. & How much time was invested in the step? Why was it different than expected? \\
            \hline
            \textbf{What is the expected result of the step?} & \textbf{Is the result as expected?} \\
            At the end of the step, what is the expected result? & Does the result match the description made pre-step? Why does it not match? \\
@@ -79,43 +79,46 @@ The next sections present the evaluation protocol and the subject of design.
        The design plan focusses on the modelling of the system.
        It is, however, not given that passing all the tests does also results in a working design.
        If the tests are incomplete or complications in the design are overlooked, the design process is worthless.
        Therefore, the model will be validated with a physical prototype of the design.
        Because the design method would be unreliable.

        Therefore, the model is validated with a physical prototype of the design.
        This shows whether the model is correct and whether all assumptions about the system are correct.
        The prototype does not only show where the design process went wrong, it can also be used to improve the design plan to prevent these modeling problems.

 \section{Subject of Design}
 \label{sec:sod}
 The choice in subject of design has a strong influence on the effectiveness of the evaluation of the design plan.
 To ensure the best subject of design a list of requirements is composed.
 Based on this list the best subject of design is a "Tweet on a whiteboard writer", which is referred to as system.
 Other subjects were considered, but did not meet the desired requirements.
    \label{sec:sod}
    The choice in subject of design has a strong influence on the effectiveness of the evaluation of the design plan.
    To ensure the best subject of design a list of requirements is composed.
    Based on this list the best subject of design I could come up with is a "Tweet on a whiteboard writer", which is referred to as system.
    Other subjects were considered, but did not meet the desired requirements.

 The most important requirement is that, while developing the system, the different aspects of the design plan are used.
 Taking into account that there is a limited time budget and that the system must be within the scope of the design plan, the set of possible subjects of design is slim.
 The time budget is set to 10 weeks of development and the system must have a dynamic system that is actuated via a software controller.
 The tweet on a whiteboard fits within these requirement as it can have interesting dynamics and has multiple features.
 Although it is possible that the system is seen as a simple wall plotter with simple XY-movement, there are alternative implementations that achieve more complex XY-movement.
 This provides the required complexity and allows for different levels of detail needed for the variable detail approach.
 The system can be split into more than one feature, which is required to evaluate the rapid development cycle.
 One of the features is the XY-movement and other features are:
    The most important requirement is that, while developing the system, the different aspects of the design plan are used.
    Taking into account that there is a limited time budget and that the system must fit within the scope of the thesis, the set of possible subjects of design is slim.
    The time budget is set to 10 weeks of development and the system must have a dynamic system that is actuated via a software controller.
    The tweet on a whiteboard fits within these requirement as it can have interesting dynamics and has multiple features.
    Although it is possible that the system is seen as a wall plotter with basic XY-movement, there are alternative implementations that achieve more complex movement.
    This provides the required complexity and allows for different levels of detail.
    The XY-movement is the basic feature and detail is added in the form of other features.
    More detailed features are, for example:
    \begin{enumerate}
        \item Lifting the marker from the board
        \item Lifting/lowering the marker from/on the board
        \item Erasing: End effector manipulation
        \item Changing color: Switching Marker
        \item Speed increase
        \item Speed improvement
    \end{enumerate}
 Similar to the XY-movement, these features have multiple implementations that add complexity to the system.
 This gives the possibility during the case study to go with a more or less complex design, allowing to fit the case study in the time budget without compromising the quality of evaluation.
    Similar to the XY-movement, these features have multiple implementations that add complexity to the system.
    This gives the possibility during the case study to go with a more or less complex design, allowing to fit the case study in the time budget without compromising the quality of evaluation.

 Although a finished product is not required, a partial prototype is part of the testing and validation procedure.
 As the design method focuses on the physical component, a mechanical prototype is important.
 The prototype would originally been constructed with the rapid prototyping facilities at the university.
 However, the COVID-19 pandemic forced the university to close and to work from home.
 This limited the rapid prototyping to DIY-tools and a 3D-printer.
 It is expected that this set of tools is sufficient to construct a prototype of the tweet on a whiteboard system 
    Although a finished product is not required, a partial prototype is part of the testing and validation procedure.
    As the design method focuses on the physical component, a mechanical prototype is important.
    The prototype would originally been constructed with the rapid prototyping facilities at the university.
    However, the COVID-19 pandemic forced the university to close, and me to work from home.
    This limited the rapid prototyping to DIY-tools and a 3D-printer.
    It is expected that this set of tools is sufficient to construct a prototype of the tweet on a whiteboard system.

 Other options that were looked at was a 3D calibration system for a positioning system.
 This idea was rejected because the complexity originated from the required accuracy instead of the dynamics.
 In other words, choosing interesting dynamics would degrade the usability of the system.
 A peg-in-hole problem, was also considered briefly as well.
 But that is mainly a complex sensing and control problem, and not dynamically interesting.
    Other options that were also considered but did not meet the requirements.
    One of these options was a 3D calibration system for a position measurement system.
    This idea was rejected because the complexity originated from the required accuracy instead of the dynamics.
    In other words, choosing interesting dynamics would degrade the accuracy of the system.
    A peg-in-hole problem, was also considered as a system.
    But that is mainly a complex sensing and control problem, and not dynamically interesting.
--- a/content/conclusion.tex
+++ b/content/conclusion.tex
@@ -1,3 +1,162 @@
 %&tex
 \chapter{conclusion}
 \label{conclusion}
 \chapter{Conclusion}
 \label{chap:conclusion}
 % Intro: end goal

 \section{Case Study}

 % Reflect: Extend the RIDM with a preliminary design phase. This makes it possible develop a system for a given problem or idea, using this design method.
 \emph{Extend the \ac{ridm} with a preliminary design phase, focussing on the physical part of \ac{cps}.}\newline
 To get from a given problem or idea, to an initial design that can be used by the \ac{ridm}, a linear set of steps was added.
 This set consists of a problem definition, requirements and initial design step.
 These steps are based on the \ac{se}-approach.

 % Reflect: Refine the RIDM to make the execution of the different design steps explicit and unambiguous.
 \emph{Refine the \ac{ridm} to make the design steps more explicit with improved instructions.}\newline
 To perform a reproducible evaluation of the \ac{ridm}, the method of the different design steps were defined more explicit.
 The \ac{ridm} specifies the development cycle and the variable-detail approach with sufficient detail, making them ready to use.
 How to define features and tests for the development cycle, were not as clearly defined.
 In this thesis, two steps were added to the design method: one with a method to define the set of features and one that is used to specify the test protocol.
 Two design steps were added in this thesis that describe a method to define the set of features and create a test protocol.
 Furthermore, a feature selection step was added to aid with the development.

 % Reflect: Develop and perform a case study that tests and evaluates the RIDM.
 \emph{Develop and perform a case study that tests and evaluates the \ac{ridm} as a design method for the physical part of \ac{cps}.}\newline
 The case study consisted of the development of a \emph{Tweet on a Whiteboard} writer.
 This development is performed according to the design plan, that was the result of the first two research objectives.
 The \emph{tweet on a whiteboard} writer was chosen as subject of design based on a set of requirements.
 The goal of these requirements is to find a subject of design that evaluates most aspects of the \ac{ridm} when implemented.

 A list of questions was formed to monitor the progress of the case study.
 The questions are answered before and after each step of the design process.
 The list was created to ensure a consistent documentation of the expected outcome and the actual outcome of each step.
 Both the expected and actual outcome are used to evaluate the design step.

 \section{\acl{ridm}}
 \emph{Assess the influence that applying the \ac{ridm} has on the design process for \ac{cps}.}\newline
 The core of the \ac{ridm} consists of the development cycle and the variable-detail approach.
 Both of these methods have specific influence on the design process.

 The development cycle introduces a feature-based approach to the development process.
 With the development cycle the system is implemented feature by feature.
 This requires the development team to split the functionality of the system into features.
 It forces the developers to go through the design in a structured manner.
 Furthermore, to determine in what order the features are implemented, the developers must establish the \emph{cost of change} and \emph{chance of failure}-metric for each feature.

 Based on the \emph{chance of failure} and \emph{cost of change} metrics, the features are ordered with the aim to reduce the impact of a design failure.
 Even though the case study only applied the feature selection twice, it proved itself useful by selecting the end-effector feature first.
 By prioritizing the end-effector, its failure had only a minor impact on the design.

 During each iteration of the development cycle, the selected feature is implemented according to the variable-detail approach.
 However, the ability to assess the influence of the variable-detail approach is limited by the absence of tooling for model organization and testing.
 Without tooling that is compatible with version control, it is difficult to switch between model versions, undo design changes, or run automated testing.
 Furthermore, as the development did not distinct between design and model, the models used often contained more detail than strictly necessary.
 Both these limitations resulted in models that would surpass the minimal required level of detail; therefore, it is not possible to assess whether the minimum required level of detail can be established with passing all the tests.
 Nevertheless, the variable-detail approach introduces a step wise addition of detail that enforces a structured method similar to the development cycle.

 It is unfortunate that the development cycle did not include a structured method to define the features nor their order of implementation.
 The performance of the variable-detail approach is currently hindered by the absence of tooling.
 Consequently, this limits the accuracy of the assessment on the actual influence of the \ac{ridm}.
 Notwithstanding these limitations, the results of the case study suggest that the structured approach of \ac{ridm} reduces the impact of design failures and reduces the development cost for \ac{cps} design.

 \emph{Describe which adaptations are required for both the \ac{ridm} and the design method to establish a competent design process for \ac{cps}.}\newline
 The \ac{ridm} required adaptations before it could be evaluated.
 The adaptations made in this thesis showed variable degrees of success during the case study.
 To create a competent design process, some adaptations must be improved and some new ones must be added.

 The produced result by the development cycle depends strongly on the provided features to implement.
 To ensure a consistent result for the design of \ac{cps}, \ac{ridm} must incorporate a design process to define these features.
 Moreover, the features must not only describe functionality, but each feature must also include a physical component and a requirement.
 These three elements together make it that features can be implemented and tested individually.

 The design process must describe a complete method from problem description till the set of features.
 In this design process, the solution to the problem is established in the form of the functionality of the system.
 The design process determines what components perform that functionality, and puts requirements on the components and the functionality.
 All design decisions made during this process shape the final product.
 Therefore, the design process to determine the features is urgently important in the ability of \ac{ridm} to successfully develop \ac{cps} from scratch.

 The variable-detail approach requires adaptations to fully utilize the advantages that the short cycle and testing provide.
 Therefore, the models must be separated from the design.
 This requires a centralized design including a database for all design parameters.
 Models are no longer required to represent the complete design, allowing for more specific models.
 Moreover, the models can conform to the general model properties.
 Because the models are more specific, more of them are required to cover all aspects of the design.

 To manage the increased number of models a form of version control is needed.
 The version control makes it possible to organize, and if necessary to combine and integrate, different models.
 Furthermore, it makes it possible to revert design changes and switch to different model versions.

 The final adaptation is the ability for automated testing.
 Automated testing provides a major advantage on top of the previous adaptations.
 As the models inherit their parameters directly from the centralized design database, every design change propagates to all models.
 With automated testing, all model are simulated after a design change. 
 This highlights any unwanted behavior caused by the design change.
 As the models are made more specific, a failed simulation of a model automatically pin points the area where the problem occurs.

 Implementing and evaluating the adaptations as described above are required to determine if these adaptations are sufficient.
 The next section describes recommendations that must be considered before implementing these adaptations.

 \section{Recommendations}
 Before any of the adaptations are applied to the \ac{ridm}, further research on the exact format of these adaptations is recommended.
 The recommended steps taken in further research are:

 \begin{itemize}
    \item \emph{Make the application area and purpose of the \ac{ridm} specific}: To design a good design method, the design process must start with a clear problem description.
        Currently, the \ac{ridm} does provide a design method, but does not state clear requirements such as:
        \begin{itemize}
            \item \emph{Type of \ac{cps}}: mainly hardware, software or control?
            \item \emph{Design focus}: improve reliability, real-time guarantee, reduce complexity, shorten development-time?
            \item \emph{Internal or external use}: is the client directly involved?
            \item \emph{Development team}: number of developers from what background?
        \end{itemize}
        These requirements improve the focus of further research.
        This focus could also help to attract and involve other organizations.
        Above all, it prevents the \ac{ridm} of becoming a "master of none".
    \item \emph{Explore existing design projects that share the application area and purpose}:
        To avoid inventing the wheel or or provide a solution none wants, it is recommended to explore existing design project. 
        Involve projects from companies and universities, successful and unsuccessful. 
        Evaluate all the projects with at least the following questions:
        \begin{itemize}
            \item What type of design paradigm or model is being applied?
            \item Where is the complexity in the project and how is it dealt with?
            \item How are the metrics of \emph{cost of change} and \emph{chance of failure} defined?
            \item How are the design and models connected?
            \item Which design tools are used by the design team? Why are they used?
            \item Are there common design problems between the different projects?
            \item How is the client involved in the development process?
            \item What considerations are made to chose between modelling or hardware prototyping?
        \end{itemize}

    \item \emph{Hypothesize the improvements provided by \ac{ridm} for existing design projects, and vice versa}: 
        Based on the evaluation of the design projects:
        \begin{itemize}
            \item How could the \ac{ridm} improve those existing design projects? 
            \item What lessons can be drawn from the existing design projects?
        \end{itemize}
 \end{itemize}

 Depending on what the results and conclusions of the recommended research topics are, a strategy has to be created to further develop the \ac{ridm}.
 Currently, there are two likely scenarios:
 \begin{itemize}
    \item Make the \ac{ridm} part of an existing design model, such that the advantages are integrated with existing design models.
    \item Develop the \ac{ridm} into a complete design method, such that it can be used for the development of the complete product life-cycle.
 \end{itemize}
 Independent of what strategy is chosen, it is recommended to:
 \begin{itemize}
    \item Implement the adaptations as described in this thesis.
    \item Perform the adaptations and improvements of the \ac{ridm} with a multi-disciplinary design team.
    \item Evaluate the \ac{ridm} with projects that are within the application area of the \ac{ridm}.
 \end{itemize}

 The recommendations result in a more focussed development of the \ac{ridm}.
 But these recommendations are only the top of the iceberg of what is required to develop \ac{ridm} as a complete design method for \ac{cps}
 Expected is that a full development of the \ac{ridm} takes multiple years and many developers and researchers to complete.

 The \ac{ridm} does bring some techniques that show potential.
 These techniques could improve existing design methods.
 Based on this thesis, the following research topics are recommended:

 \begin{itemize}
    \item \emph{A technique or protocol for to organize the parameters of a design, such that the parameters can be used in modelling}: Can the current modelling tools be adapted to read parameters from a database and can design tools be adapted to write parameters to a database?
    \item \emph{Tooling for modelling software, to allow for unit testing}: Software development applies unit testing, where behavior of each function is tested separately.
        In modelling this would allow every sub-model to be tested separately.
 \end{itemize}
--- a/content/input/speclistc.tex
+++ b/content/input/speclistc.tex
@@ -1,5 +1,5 @@
 \item While writing, the SCARA must have a writing speed of at least 1.5 characters per second.
 \item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least three characters at that position.
 \item When the SCARA finished writing at their current position, the Cable bot shall move the SCARA to it's next position where it can write the subsequent characters.
 \item When the SCARA has to be moved to a new position, the Cable bot shall perform this movement within one second.
 \item When the system changes from writing to wiping or vice-versa, the SCARA and End-effector should change the tool within ten seconds.
 \item While writing, the \ac{scara} must have a writing speed of at least 1.5 characters per second.
 \item When the \ac{cdc} is at a static position, the \ac{scara} must be able to write at least three characters at that position.
 \item When the \ac{scara} finished writing at their current position, the \ac{cdc} shall move the \ac{scara} to it's next position where it can write the subsequent characters.
 \item When the \ac{scara} has to be moved to a new position, the \ac{cdc} shall perform this movement within one second.
 \item When the system changes from writing to erasing or vice-versa, the \ac{scara} and End-effector should change the tool within ten seconds.
--- a/content/input/systemtest1.tex
+++ b/content/input/systemtest1.tex
@@ -5,7 +5,7 @@
        \tcbline
        \begin{description}
            \item[Features:] SCARA
            \item[Specifications:] 3, 7, 11, 13, 14
            \item[Requirements:] 3, 7, 11, 13, 14
            \item[Results:] The test passes when:
                \begin{itemize}
                    \item Rectangle height is at least \SI{50}{\milli\meter}
--- a/content/input/systemtest6.tex
+++ b/content/input/systemtest6.tex
@@ -7,7 +7,7 @@
        \tcbline
        \begin{description}
            \item[Features:] SCARA, Cable Bot
            \item[Specifications:] 3, 4, 9, 11, (12)
            \item[Requirements:] 3, 4, 9, 11, (12)
            \item[Results:]
                The test passes when:
                \begin{itemize}
--- a/content/introduction.tex
+++ b/content/introduction.tex
@@ -2,19 +2,20 @@
 \chapter{Introduction}
 \label{introduction}
 \section{Context of this Thesis}
    \ac{cps} are computer systems which control and monitor a physical system.
    \ac{cps} contain systems that control and monitor their included physical system parts \autocite{rajkumar_cyber-physical_2010}.
    This physical system is often a system of mechanical components which are deeply intertwined with the software components.
    Automobiles, robots, medical devices and even the smart grid are examples of \ac{cps}.
    The complexity of \ac{cps} has gone from an embedded system that improved the fuel consumption of a car engine to a fully self-driving vehicle.
    Although the complexity opens up more design possibilities, improved efficiency, and beter safety, it has downsides as well.
    A major downside with the increasing complexity is the resulting increased developing cost and the decreasing reliability.
    \textcite{broenink_rapid_2019} introduce a new design method for \ac{cps} that aims to deal with the downsides of the complexity.
    Throughout this thesis, the term '\acl{ridm}' or abbreviated to \acs{ridm}, is used to refer to the design method by \textcite{broenink_rapid_2019}. \acused{ridm} %Set acronym to used. From here only small is set.
    The \ac{ridm} adopts a design technique called rapid development that splits the development process into small individual steps
    Where each of these steps are implemented and tested separately.
    The complexity of \ac{cps} has gone from an embedded system that improved the fuel consumption of a car engine to a fully autonomous vehicle.
    Although the complexity opens up more design possibilities, improved efficiency, and better safety, it has downsides as well.

    Major downsides with the increasing complexity are the increasing developing cost and the decreasing reliability.
    \textcite{broenink_rapid_2019} introduced a new design method for \ac{cps} that aims to deal with the downsides of the complexity.
    Throughout this thesis, the term \emph{\acl{ridm}}, abbreviated to \acs{ridm}, is used to refer to the design method by \textcite{broenink_rapid_2019}. \acused{ridm} %Set acronym to used. From here only small is set.

    The \ac{ridm} adopts a design technique called rapid development that splits the development process into small individual steps, where each of these steps are implemented and tested separately.
    Testing each individual step creates feedback on a short interval, finding errors in the design as early as possible.
    In the worst case scenario, the time and resources spent on development from the error being made till the error being detected are lost.
    The sooner an error is found, the less time and resources are wasted.
    When a test reveals an error in the design, the worst case scenario is that all resources invested since the error was made are lost.
    Errors are unavoidable, but detecting them as early as possible reduce the amount of lost resources.

    As part of the research, Broenink and Broenink performed a small case study.
    In this case study, they have designed a controller, and implemented the controller in software for a physical off-the-shelf system.
@@ -25,38 +26,38 @@
 \section{Research Objective}
    \textcite{broenink_rapid_2019} present a case study in their paper, developing a software based control system following the \ac{ridm}.
    About the result of that case study they state that "this [case study] does not mean that the same techniques cannot be applied to the physical part of the system."
    In this thesis, I will research whether the \ac{ridm} applies to the physical part of a \ac{cps}, to come to a design method that can be applied on both the physical and cyber (software) part of a \ac{cps}.
    However, the paper makes no attempt to offer a comprehensive design method to be used out of the box.
    The \ac{ridm} does not provide information about bringing a system into being, it does not address problem definition, specifications or initial design steps.
    In this thesis, I research whether the \ac{ridm} applies to the physical part of a \ac{cps}, to come to a design method that apply on both the physical and cyber (software) part of a \ac{cps}.

    The paper makes no attempt to offer a comprehensive design method to be used out of the box.
    The \ac{ridm} does not provide information about bringing a system into being, it does not address problem definition, requirements or initial design steps.
    Another weakness is that the \ac{ridm} gives no explanation of how the design steps are executed, only specifying that they are used.
    The design method would have been more useful if the authors had made a complete design method available to accompany their paper.
    To ensure that the \ac{ridm} can be assessed as a design method for \ac{cps}, I have the following research objectives:
    To assess the \ac{ridm} as a design method for \ac{cps}, I set the following research objectives:
    \begin{itemize}
        \item Extend the \ac{ridm} with a preliminary design phase.
            This makes it possible develop a system for a given problem or idea, using this design method.
        \item Refine the \ac{ridm} to make the execution of the different design steps explicit and unambiguous.
        \item Develop and perform a case study that tests and evaluates the \ac{ridm}.
        \item Extend the \ac{ridm} with a preliminary design phase, focussing on the physical part of \ac{cps}.
        \item Refine the \ac{ridm} to make the design steps more explicit with improved instructions.
        \item Develop and perform a case study that tests and evaluates the \ac{ridm} as a design method for the physical part of \ac{cps}.
    \end{itemize}
    Based on the results of the case study I will answer the following research questions:
    Evaluation of the \ac{ridm} as a design method is done with the results of the case study as the following objectives:
    \begin{itemize}
        \item Which design techniques of the design method by \textcite{broenink_rapid_2019} can be applied developing the physical part of \ac{cps}?
        \item Which adaptations are required to make the design method by \textcite{broenink_rapid_2019} suitable for developing the computation and physical part of \ac{cps}?
        \item Assess the influence that applying the \ac{ridm} has on the design process for \ac{cps}.
        \item Describe which adaptations are required for both the \ac{ridm} and the design method to establish a competent design process for \ac{cps}.
    \end{itemize}

 \section{Approach}
    The goal of this thesis is to evaluate the \ac{ridm}, a design method by \textcite{broenink_rapid_2019}.
    Their design method is evaluated in the form of a case study.
    The goal of this thesis is to evaluate the \ac{ridm}, in the form of a case study.
    The case study consists of a \emph{design process}, developing a \ac{cps} according to the \ac{ridm}.
    Based on the results of the design process, the \ac{ridm} is evaluated.
    However, there are a couple of steps required prior to the start of the case study.

    The first step is to produce a concrete \emph{design plan} based on the design method.
    The concrete design plan improves the evaluation of the design techniques.
    The design method is presented in an abstract form which leaves room for interpretation.
    This abstract form hampers the evaluation process, as the ambiguity of the design method makes it difficult to point out flaws in the design method.
    Therefore, I will assess the design method and add detail to make a more concrete design plan.
    Because the design method focusses on the rapid development principles and modelling techniques, it does not cover the design steps outside of that focus.
    These steps, like problem definition and system specifications, are a crucial part of the design process and are added to create the concrete design plan.
    The added steps are based on the steps from the \emph{\ac{se}} approach.
    Therefore, I assess the design method and add detail to make a more concrete design plan.
    Because the \ac{ridm} focusses on rapid development principles and modelling techniques, it does not cover the design steps outside of that focus.
    These steps, like problem definition and system requirements, are a crucial part of the design process and are added to create the concrete design plan.
    The added steps are based on the steps from the \emph{\ac{se}} approach \autocite{blanchard_systems_2014}.
    \begin{figure}
        \centering
        \includegraphics[width=9cm]{graphics/approach.pdf}
@@ -70,7 +71,6 @@
    The evaluation protocol consists of a list of questions that are evaluated for each design step.
    The protocols contains questions about the design method itself, thus evaluating the instruction of each design step.
    Other questions are about the design process, covering the execution of the instructions.
    %There are questions that evaluate the design plan and there are questions that evaluate the design process.
    The other step is to provide the \emph{subject of design} to develop in the case study, essentially defining a problem that has to be solved.
    How all these components combine into the case study is shown in \autoref{fig:approach}.

@@ -78,29 +78,30 @@
    However, the goal of this research is to use the design process to evaluate the design method, not to develop a product.
    A possible pitfall is that during the design process the developer finds a simple solution, such that the design techniques to deal with the increased complexity are left untouched.
    Therefore, it is important to guarantee a minimum level of complexity.
    Instead of setting a problem that is very complex, I decided to require a minimum complexity to the solution.
    Instead of defining a problem that is very complex, I decided to require a minimum complexity to the solution.
    This makes the design process complex enough, without requiring an excessive amount of development time or compromising the quality of the evaluation.

    Together with some other practical requirements, the best subject of design found is "Writing a tweet on a whiteboard".
    The subject of design is interesting because it has multiple design solutions that are complex but not unpractical.
    Furthermore, it has some interesting dynamics, requires a control law, and can easily be constructed in to a prototype.
    Furthermore, it has some interesting dynamics, requires a control law, and can easily be constructed into a prototype.

    With a subject of design that requires a solution in the form of an object incorporating both physical and cyber parts to develop;
    With a subject of design that requires a solution in the form of an object that incorporates both physical and cyber parts to develop;
    a design plan which describes how to develop this solution;
    and a protocol to evaluate the design plan and the development of the solution;
    the case study is executed.
    From the results of the case study I propose multiple improvements to the design method, not only for the physical part of \ac{cps} but also the cyber part.

 \section{Structure}
    The overall structure of the study takes form of seven chapters.
    The first two chapters introduce the used design methods.
    The thesis is structured as follows:
    The first two chapters introduce the design methods.
    \autoref{chap:background} gives a background of the \ac{ridm} and \ac{se} approach and how this is combined into the design plan.
    The design plan is presented in full detail in \autoref{chap:analysis}, where each step is explained.
    The design plan is presented in detail in \autoref{chap:analysis}, where each step is explained.

    The next three chapters cover the method, execution, and evaluation of the case study.
    \autoref{chap:case_method} is concerned with the methodology of the case study, introducing the subject of design and the evaluation protocol.
    The next three chapters cover the case study:
    \autoref{chap:case_method} explains the method of the case study, the subject of design and the evaluation protocol.
    \autoref{chap:case_experiment} documents the execution of the case study, showing the development during the design process.
    All the questions and observations that were administered by following the evaluation protocol during the case study are analysed in \autoref{chap:case_evaluation}.
    
    The last two chapters will reflect on the design plan that is evaluated in this research.
    The last two chapters reflect on the design plan that is evaluated in this research.
    \autoref{chap:reflection} uses the evaluation results of the case study to reflect on the design plan in this thesis.
    And finally, the research is concluded in \autoref{chap:conclusion}.
--- a/content/reflection.tex
+++ b/content/reflection.tex
@@ -1,100 +1,209 @@
 %&tex
 \chapter{Design Method Evaluation}
    \label{chap:reflection}
    This chapter evaluates the design method as described in \autoref{chap:analysis}.
    The first section is about the system complexity of \ac{cps}.
    The second section evaluates the elements of a feature.
    The third section discusses the difference between model and design.
    The preparation phase and the \ac{ridm} are discussed in the last two sections.


    \section{System Complexity}
        \autoref{sec:time_investment} explains the time resources required for the development of the software in the system.
        Even though the focus was creating a hardware focussed solution for the "Tweet on a whiteboard", the complexity of the software required for this system was underestimated.
        \textcite{royce_managing_1970} also acknowledges this difference in complexity for soft and hardware.
        He expects 50 pages of software documentation for each page of hardware documentation in projects with comparable budget.
        
        Although the focus was on complex hardware solution, this solution was only possible with the use of software.
        The interaction between the \ac{scara} and \ac{cdc} is only possible with software that can switch states.
        Furthermore, the path planning that writes characters on the board is completely dependent on software as well.
        \textcite{sheard_718_1998} discusses that pure-hardware solution are relatively simple in their problem space perspective.
        However, the hardware solution is often complex in the solution space perspective 
        And indeed, during the initial design in the case study, the choice was made for the most complex hardware solution.
        Even though the hardware is more complex, without software, the \ac{scara} and \ac{cdc} have no functionality.

        Another point on system complexity is prototyping.
        Because hardware tends to be relatively simple, building a hardware prototype such as the \ac{scara} is cheap and quick.
        An initial hardware prototype is easily constructed with \ac{ots} readily available.
        Because the hardware transfers power the interfacing between components is trivial.
        For example, linear actuation can be achieved with a rack and pinion construction, linear motor, gear and chain link, or a connecting rod.
        This might not be part of the final product, but it is useful to investigate the feasibility of the project.

        Furthermore, the changes are also easily made to hardware.
        It is possible to weld or glue on new parts or remove them with the angle grinder.
        Adding components to software is tedious and can lead to unwanted behavior.
        However, this is difficult to test because the software is more complex.
        Moreover, unwanted behavior of the hardware is discoverable, and when it breaks it is often destructive.
        The software can run for multiple days before crashing, as a result of integer, stack or buffer overflows for example.

        As long as the development is still in progress, one hardware prototype is more malleable than the software in terms of resources.
        However, when the designed system is put into production, changing multiple hardware systems becomes economically unviable.
        A design method for \ac{cps} must acknowledge that the inherent complexity of software comes with a high \emph{cost of change} and a high \emph{chance of failure}.
        Additionally, the design method must use the hardware prototype low \emph{cost of change} to its advantage.


    \section{Elements of a Feature}
        Over the course of this study, the definition of a feature evolved into requirements, components and functions.
        As explained in the background chapter, having an approach to determine requirements is a crucial concept of a design process.
        Because \ac{ridm} did not include such an approach, a \ac{se} approach was added.
        The aim of the \ac{se} approach is to deliver a set of features to be used in the \ac{ridm}.
        To be more specific, the set of features was expected to be the result of the feature definition step.
        Contrary to that expectation, multiple attempts for this step did not produce a satisfactory definition of features.
        As explained in \autoref{sec:case_featuredefinition}, there was a clear discrepancy between the expected and resulting features.
        It was expected to get features in the form of components that developed during the design process.
        However, the resulting features came off as functions of the system.
        In the end, a solution was found in the RobMoSys approach.
        Even though the RobMoSys approach was too comprehensive for this case study, it provided the basis for the split between functions and components.
        Furthermore, it resulted in the hierarchical structure of functions and sub-functions as shown in \autoref{fig:robmosys}.
    The design plan as described in \autoref{chap:analysis} improves the feature definition by adding more structure.
    The goal of this extra structure was to make a design from scratch possible.
    A distinction was made between functional features and component features.
    The functional features are obtained by splitting the functionality of the system, which are then organized in a hierarchical tree.
    The hardware, which provides a platform for the functionality, is split into component features.
    These component features form the bottom layer of the hierarchical tree.

    Still, the current approach does not provide sufficient structure to define the features of the system effectively.
    The evaluation of the feature definition (\autoref{sec:case_featuredefinition_evaluation}) points out that it does not provide any structure for components.
    It is currently not possible to define sub-components for components.
    Furthermore, making connections between a task or mission and a (sub-)component would make the hierarchical structure unclear.

    Another point is that the current approach creates a set of requirements and a set of features.
    The original plan was to distribute the requirements along the features.
    However, this was more complex than expected and ended up in the background.

    A more suitable approach for the definition of features is a \ac{se} process that is known as functional decomposition.
    \textcite{kordon_model-based_2007} describes this process as a method for structured decomposition of the functionality of a system.
    Instead of one hierarchical structure that contains functions and components, the process results in three separate hierarchical structures.
    Each of these structures describe the elements and sub-elements for functionality, physical components and system requirements separately.
    Between the elements in these structures are connections created that describe the relationships.
    These relationships describe the link between functions, components and the rationale for requirements.

    % Deze structuur als resultaat van de functional decomposition heeft een aantal belangrijke voordelen.
    % Het design plan in deze thesis behandeld features of als component of als functie.
    % Zoals beschreven in de vorige paragraaf wordt de functionaliteit van hardware vaak gedefinieerd met software.
    % Enkel een component of functie implementeren levert niet een functionerende of testbare feature op.
    % Door op basis van de relatie tussen de elementen een functie, component en requirement samen te nemen wordt een testbare feature gevormd.
        \begin{figure}
            \centering
            \includegraphics[width=85mm]{graphics/functional_relation.pdf}
            \includegraphics[width=89mm]{graphics/functional_relation.pdf}
            \caption{Relations and elements within a feature. \autocite{kordon_model-based_2007}}
            \label{fig:functional_relation}
        \end{figure}
    Using the structure provided by functional decomposition has a couple of advantages.
    The current design plan as described in this thesis, considers the feature as a component or a function.
    As explained in the previous section, the hardware gets its function from the software.
    Implementing an individual function or component does not deliver a testable feature.
    
    With this new approach, a feature can be formed by grouping the elements that are connected via the defined relationships (\autoref{fig:functional_relation}).
    This feature describes a function that is performed by a component.
    Furthermore, the requirement specifies both the function and component, and the requirement defines the test of the feature.

    % In tegenstelling tot dit design plan splits de functional decomposition het systeem over meerdere iteraties.
    % Dit voorkomt dat eerst alle requirements vastgelegd worden om later nog eens alle functionaliteit op te splitsen.
    % In de case study werd tijdens het opsplitsen van de functionaliteit duidelijk dat er requirements gemist waren.
    % En later ook nog dat bij het splitsen van de functionaliteit geen order of operation was gespecificeerd.
    Contrary to the design plan in this thesis, the \ac{se} process decomposes the functionality of the system over multiple iterations.
    This is a significant improvement compared to the current approach, in which all requirements were determined before any features was defined.
    The feature definition during the case study, showed that specific requirements were overlooked.
    Later, while defining the test protocol, it became clear that no order of operation was specified.

    % Functional decomposition of een ander gelijkwaardig SE process verbeterd niet alleen de feature definition, maar de preparation phase in het geheel.
    % Het beschrijft een beproefd process dat van een problem description een degelijke featureset kan opzetten.
    Functional decomposition, or a similar \ac{se} process, would not only improve the feature definition step, but the preparation phase as a whole.
    Future implementations of the \ac{ridm} must consider such a process, as it provides a structured method to develop a solution for a problem.
    Whereby the solution is split in to a elaborate set of features.

        Creating a hierarchy for the functions and a separate set of components allowed for the continuation of the case study.
        There were still a number of challenges with this approach.
        For example, it was almost impossible to divide the requirements between components and functions.
        Furthermore, the role of electronics did not fit in the current approach either.
        In reviewing the literature, the approach used in this case study shows clear resemblances with \ac{mbed} \autocite{kordon_model-based_2007}.
        \ac{mbed} introduces explicit relations between the requirements, components and functions, as shown in \autoref{fig:functional_relation}.
        Additionally, the paper includes a layout for the hierarchy of requirements, functions and components.
        Based on this, the approach by \textcite{kordon_model-based_2007} further supports the idea of dividing features into requirements or requirements, functions, and components.

        What is interesting about this new insight is that it helps to understand the difference with the case study performed by \textcite{broenink_rapid_2019}.
        The hardware components used by Broenink and Broenink was a mini-segway, which was designed to be used in a under-graduate practical.
        The requirement for this mini-segway to be able to balance, drive and steer, is inherited directly from the student project.
        Causing the requirements and components to be implicitly defined in their case study.
        Therefore, the function that needs to be implemented, fits very well within the definition of a feature.

 %        Over the course of this study, the definition of a feature evolved into requirements, components and functions.
 %        As explained in the background chapter, having an approach to determine requirements is a crucial concept of a design process.
 %        Because \ac{ridm} did not include such an approach, a \ac{se} approach was added.
 %        The aim of the \ac{se} approach is to deliver a set of features to be used in the \ac{ridm}.
 %        To be more specific, the set of features was expected to be the result of the feature definition step.
 %        Contrary to that expectation, multiple attempts for this step did not produce a satisfactory definition of features.
 %        As explained in \autoref{sec:case_featuredefinition}, there was a clear discrepancy between the expected and resulting features.
 %        It was expected to get features in the form of components that developed during the design process.
 %        However, the resulting features came off as functions of the system.
 %        In the end, a solution was found in the RobMoSys approach.
 %        Even though the RobMoSys approach was too comprehensive for this case study, it provided the basis for the split between functions and components.
 %        Furthermore, it resulted in the hierarchical structure of functions and sub-functions as shown in \autoref{fig:robmosys}.
 %
 %
 %        Creating a hierarchy for the functions and a separate set of components allowed for the continuation of the case study.
 %        There were still a number of challenges with this approach.
 %        For example, it was almost impossible to divide the requirements between components and functions.
 %        Furthermore, the role of electronics did not fit in the current approach either.
 %        In reviewing the literature, the approach used in this case study shows clear resemblances with \ac{mbed} \autocite{kordon_model-based_2007}.
 %        \ac{mbed} introduces explicit relations between the requirements, components and functions, as shown in \autoref{fig:functional_relation}.
 %        Additionally, the paper includes a layout for the hierarchy of requirements, functions and components.
 %        Based on this, the approach by \textcite{kordon_model-based_2007} further supports the idea of dividing features into requirements or requirements, functions, and components.
 %
 %        What is interesting about this new insight is that it helps to understand the difference with the case study performed by \textcite{broenink_rapid_2019}.
 %        The hardware components used by Broenink and Broenink was a mini-segway, which was designed to be used in a under-graduate practical.
 %        The requirement for this mini-segway to be able to balance, drive and steer, is inherited directly from the student project.
 %        Causing the requirements and components to be implicitly defined in their case study.
 %        Therefore, the function that needs to be implemented, fits very well within the definition of a feature.

    \section{Model and Design Relation}
        \label{sec:evaluation_model_and_design}
        The \ac{ridm} as well as the design method in this study do not make an explicit distinction between the model and the design.
        This implicitly causes the model itself to dictate the design.
        According to \textcite{stachowiak_allgemeine_1973}, three general properties apply for a model.
        First is that the model is always representative to its original; 
        This implicitly resulted in a model that represents the complete design.
        Over the course of the development the complexity of the design increased, resulting in more complex modelling as well.
        The model used in the case study was first implemented as a kinematics model, and as the design became more complex it was represented with 2D and 3D physics, and a CAD drawing.

        There are two issues with this approach:
        first, that the approach does not comply with the general model properties;
        second, the parameters of the design are represented by multiple models.

        \subsection{Model properties}
        According to \textcite{stachowiak_allgemeine_1973}, three general properties apply for a model:
        first is that the model is always representative to its original; 
        second, the model must only include attributes of its original that are relevant to the respective developer or user;
        and third, the model must be pragmatic to the original, meaning that models are an adaptation of the original with respect to a specific purpose.

        These properties coincide with the different modelling approaches used during the case study.
        The dynamic models did not start directly with 3D physics as it would conflict with the second property.
        However, as the design becomes more refined, it can not be represented with only basic kinematics calculations. 
        The step to 2D, and later 3D physics, is made such that the model still represents the design.
        Parallel to the dynamics model, a CAD drawing was used to model the shape of the hardware components.
        Simply because models represent the design for a different purpose.

        Even though the models in the case study satisfy the properties as described above, it has a significant implication for the current design method.
        As the model is used to represent the current design, switching to a different modelling approach changes the representation of the design as well.
        Two direct consequences are identified from the case study.
        The first is that there is discrepancy for the required effort between a design change and the corresponding model update.
        This is seen in the case study when the model was reconstructed with 3D physics but the design did not change.
        Resulting in a couple of days of work spend reconstructing the model, without significant progress in the design.
        The second consequence is that the design got split up over the dynamics model and the CAD drawing:
        Both included the kinematics of the \ac{scara};
        the controller and stepper behavior was defined in the dynamics model;
        and the shapes of the components was defined in the CAD drawing.
        This organization of models and design has two major downsides.

        The first that a switch in modelling approach, is not only labor intensive, it is error prone as well.
        Copying parameters from one model and pasting them in another model is an unwanted practice.
        The second problem is that not every type of model can represent the same information.
        Although the CAD drawing contains a lot of detail, it cannot represent the electric behavior of the motors.
        For this case study the motors are \ac{ots}-components.
        The electric behavior of the motor is therefore represented by a product number.
        However, this is not applicable when the design requires custom motors that are designed with a specific electric behavior.
        Probably resulting in a situation where specific design details are spread over different sub-models.
        Such a subdivision of details across different models is, without any doubt, undesired.
        The first property applies to the model because the model represents the full design, and is therefore always representative.
        However, because the model represents the full design, it violates the second and the third property.
        The models used in the case study include all attributes of the design and it lacks a specific purpose.

        Consequently, the models become overly complex.
        Especially for larger designs the model complexity drastically decreases simulation speed for dynamic systems.
        But it also complicates finding bugs in the model.

        \subsection{Design Parameters}
        The design of the \ac{scara} is currently represented by two types of models: a dynamics model and a CAD drawing.
        Both these modelling types have different purposes and represent different aspects and parameters of the design.
        However, both models share parameters of the design as well.

        For the \ac{scara} design, the dynamics represent mostly the motor and controller behavoir.
        The CAD drawing represents the shape of the components.
        But the kinematics play an important role for both models.
        A direct result from this is that it increases the \emph{cost of change}.
        When the design changes, the changes must be applied for both models, increasing the amount of work.

        This distribution of design parameters has more disadvantages, as copying the parameters between different models is error-prone and labor-intensive.
        The case study in this thesis is small, but did already involve 8 different models spread over 4 different modelling approaches.
        For larger design projects, it is almost given that copying of parameters would result in problems with the design process.
        Having design parameters distributed across different models is, without any doubt, undesired.

        \subsection{Structured design and models}
            To solve these problems, the design method must have a strategy for organizing the design and the corresponding models.
            This consist of a centralized design, which is validated with the use of models.
            Important is that every model inherits from the design.

            The three general properties must apply to every model made.
            Instead of creating a model of the complete design, only small parts of the design are modelled.
            
            Additionally, a method to organize all design parameters reduces the \emph{cost of change}.
            The goal is that all the models automatically use the design parameters from a centralized location.
            Any changes to the design are made at that centralized location, each model can than be tested automatically with the updated parameters.
            This eliminates copying of parameters and allows for automated testing.
            It removes the human factor and produces direct feedback about the design change.

    \section{Preparation Phase}
        The start of this chapter explains the reason to prepend the preparation phase to the \ac{ridm}.
        Where the preparation phase aims to produce the requirements and features, based on the waterfall method.
        However, during the case study, the waterfall method proved to be problematic.
        Especially during the first steps, the amount of information was scarce, which made it tempting to work ahead.
        For example, a simple proof of concept during the requirement step would have resulted in valuable information.
        This was however, not possible as the goal was to follow the specified design method as close as possible.

        Looking at the current case study where the system under design is relatively simple, more design experience is sufficient to overcome the information shortage.
        Unfortunately, it requires experienced developers, which are scarce by themself.
        As was pointed out in \autoref{sec:evaluation_reflection_protoype}, perceiving the current design as a prototype would also improve the information situation.
        Similarly, \textcite{royce_managing_1970} proposed to use a prototype in order to reduce the reliance on human judgment.
        A common denominator of these proposals is that they all deal with the dependency on human judgement, either by improving or reducing this judgement.
        Nonetheless, these proposal seem like a suppression of symptoms, instead of an actual improvement of the design method.

        Interestingly, when the current design is regarded as prototype and the design method is repeated, the approach is comparable with the first cycle of the spiral model \autocite{boehm_spiral_1988}.
        \textcite{broenink_rapid_2019} state about the \ac{ridm} that the development cycle is based, among other methods, on the spiral model.
        It may be the case therefore that prepending the waterfall model was an attempt to reinvent the wheel.
        Initially adding a preparation phase to the \ac{ridm} was not within the scope of the thesis.
        Causing me to underestimate the role that the preparation phase had for the \ac{ridm}.
        In hindsight it is clear that the preparation phase is crucial for the design process, and thus also for the evaluation of \ac{ridm}.
        The linear set of steps were chosen as it was trivial to put those in front of the \ac{ridm}.
        However, the linear set of steps proved to be inapt for the development of complex \ac{cps}.

        Without a concrete approach\footnote{Here, I specifically use the term approach because preparation phase implies that it must be a phase prior to the \ac{ridm}.} to get from a \emph{problem} to a functional design with features, the \ac{ridm} is unsuitable for the development of \ac{cps}.
        Describing such an approach is far outside of the scope of this thesis.
        Nonetheless, several \ac{se} processes offer a possible solution, such as functional decomposition, state analysis \autocite{ingham_engineering_2005} or spiral model \autocite{boehm_spiral_1988}.
        Furthermore, the advantages of modern techniques of rapid prototyping should also be considered to aid the design process.

        A possible candidate for the approach is to use a spiral model as basis and apply the techniques of \ac{ridm}, rapid prototyping and functional decomposition in that basis.
        Another option is to extend the development cycle of \ac{ridm} with functional decomposition and rapid prototyping.
        Further research is required to determine the optimal approach for the \ac{ridm}.
        This research should use data and experience from existing design projects.
        Above all, the design of such an approach needs direct involvement of experienced systems engineers.
        
    \section{Rapid Iterative Design Method}
        This chapter began by a breakdown of the elements of a feature, argued the importance of distinction between design and model, and explained the need for an integrated preparation phase.
        The commonality between these three issues is that they all stem from the rapid development cycle, which was introduced in \autoref{sec:background_rdc} as part of the \ac{ridm}.
@@ -102,47 +211,47 @@
        Further studies, which take these issues into account, should be undertaken.

        Even though, these issues have a large impact on the overall performance, they must not overshadow the rest of the design method.
        The feature selection step and variable detail approach did show a positive impact on the design method.
        The feature selection step and variable-detail approach did show a positive contribution to the design method.
        The following sections discuss their performance and what potential impact an improved rapid development cycle introduces.

        \subsection{Feature Selection}
            The goal of the rapid development is to process a list of features into a competent model.
            In this case, the list of features was produced in the preparation phase.
            The features are then, one by one, implemented according to the variable detail approach.
            The features are then, one by one, implemented according to the variable-detail approach.
            To determine the order of feature implementation, I specified a feature selection protocol, which is explained in \autoref{sec:feature_selection}.
            Based on this case study, the feature selection is a suitable addition to the design method.
            Especially for the failed feature implementation as described in \autoref{sec:case_development_cycle_1}.
            Would the SCARA have been implemented first, a failure in the end-effector might result in a required redesign of the SCARA feature.
            Would the \ac{scara} have been implemented first, a failure in the end-effector might result in a required redesign of the \ac{scara} feature.
            However, with only two uses during this case study, caution must be applied.

            On the criteria itself, the time-risk factor and the dependees are, in my opinion, most relevant.
            The dependees is a hard criteria: if there are any features that it depends on, but not yet implemented, it is cannot be selected.
            Of the criteria used in the selection, the \ac{cof}-time factor and the dependees are, in my opinion, most relevant.
            The dependees is a hard criterium: if there are any features that it depends on, but not yet implemented, it cannot be selected.
            Otherwise the feature would be implemented before the required information is available.
            As explained in \autoref{sec:case_development_cycle_1}, the feature selection approach aims to clear the largest amount risk the smallest amount possible.
            However, between the dependees and the risk-time factor, there is a criteria for the number of tests, which could hinder this approach.
            The current approach would result in the situation where a feature with lots of easy to pass tests, is implemented before a features with less, but more difficult tests.
            As explained in \autoref{sec:case_development_cycle_1}, the feature selection approach aims to clear the largest amount \ac{cof} in the smallest amount of time possible.
            However, between the dependees and the \ac{cof}-time factor, there is a criterium for the number of tests, which could hinder this approach.
            The current approach would result in the situation where a feature with lots of easy-to-pass tests, is implemented before a features with less, but more difficult tests.
            It is then possible to spend a lot of time on something that is very likely to pass anyway.

            This does not alter the fact that to complete the design the all tests have to pass.
            Which is also the reason for this criteria in the first place: give priority to the feature that passes the most tests on completion.
            Even though it is difficult to draw concrete conclusions about the feature selection, a recommendation is to use the number and risk of tests as a metrics for the risk-time factor calculation.
            In addition, it is possible that other metrics improve the risk time calculation, such as the number of dependees, the number of tests of those dependees, or other metrics that aid the risk assessment.
            Further work is required to establish which metrics are suitable to improve the risk calculation.
            This does not alter the fact that to complete the design all tests have to pass.
            That all test have to pass is also the reason for this criterium in the first place: give priority to the feature that passes the most tests on completion.
            Even though it is difficult to draw concrete conclusions about the feature selection, a recommendation is to use the number of tests and the change of failure for each test as a metric to calculate the \ac{cof}-time value.
            In addition, other metrics and approaches that can improve the \ac{cof}-time calculation are: number of dependees, the number of tests of those dependees, and planning poker.
            Further work is required to establish which metrics are most suitable to calculate the \ac{cof} values.

        \subsection{Variable Detail Approach}
            The variable detail approach is be a very practical development tool.
            A note of caution is due here since the variable detail approach has not been used to its full potential.
        \subsection{Variable-Detail Approach}
            The variable-detail approach is a very practical development tool.
            A note of caution is due here since the variable-detail approach has not been used to its full potential.
            The goal was to add detail to a feature in strictly defined steps.
            Between each step the tests are applied to the updated model.
            Based on the test, the development continues or the model is rolled back to an earlier version.
            In addition, the models, independent of the level of detail, can be reused in other models.
            
            However, multiple difficulties were encountered during the case study, which hindered the variable detail approach.
            However, multiple difficulties were encountered during the case study that hindered the variable-detail approach.
            As was mentioned in \autoref{sec:evaluation_reflection_development}, the lack of good version control made it difficult to work with multiple versions of a model.
            This made it difficult to switch or revert to other levels of detail.
            However, the greatest difficulty is due to the model representing the design, as discussed in \autoref{sec:evaluation_model_and_design}.
            Because the design contains a certain level of detail and the model is a full representation of the design, it is difficult to make a simple implementation or to switch back.
            Because the design contains a high level of detail and the model is a full representation of the design, it is difficult to make a simple implementation or to switch back.
            This strong relation between the model and the design, also caused the complete model to be switched to a different representation.
            
            Even though the variable detail approach did not perform as planned, I expect this approach to be a very strong part of the design method, given that a solution is found to the problems described above.
            Even though the variable-detail approach did not perform as planned, I expect this approach to be a very strong part of the design method, given that a solution is found to the problems described above.

--- a/content/samenvatting.tex
+++ b/content/samenvatting.tex
@@ -1,3 +0,0 @@
 %&tex
 \chapter*{samenvatting}
 \label{samenvatting}
--- a/content/summary.tex
+++ b/content/summary.tex
@@ -1,3 +1,34 @@
 %&tex
 \chapter*{summary}
 \label{summary}
 \chapter*{Summary}
 \label{chap:summary}

 % Het Waarom van je onderzoek
 Testing is an incredibly important part of the design process.
 Before a quality product is put into production, it has gone through extensive testing procedures.
 Likewise, new design methods have to be tested before they can be used in a design project.

 The \ac{ridm} is a proposed feature-based design method for rapid development of \ac{cps}.
 Using \ac{ridm} the system is divided into a set of features.
 Each feature represents a part of the system functionality.
 By implementing and testing one feature at the time it provides a structured method to deal with the complexity of \ac{cps}.

 % Het hoe van je onderzoek, de daarbij gebruikte methodes
 This thesis evaluates if the \ac{ridm} is a suitable design method for the hardware-side of \ac{cps}.
 For the evaluation, a system is designed using the \ac{ridm} as a case study.
 Prior to the case study, some adaptations are made in order to use the design method for hardware.
 These adaptations add steps to create the set of features for a given design problem.

 % De belangrijkste bevindingen
 The \ac{ridm} focusses more on how to implement the features and less on how to define the features.
 However, the case study showed that the method of defining features is crucially important to the outcome of the design process.
 Another important finding is that a feature cannot be described with functionality alone.
 To be able to implement and test a feature, it must describe requirements and components as well.

 Overall, the \ac{ridm} shows real potential to improve the design process of \ac{cps}.
 The approach to determine the order in which features are implemented greatly reduces the impact of design failures.
 Unfortunately, most of the \ac{ridm} is currently hindered due to a lack of tooling.

 % De belangrijkste aanbevelingen.
 The main findings in this thesis suggest that the \ac{ridm} must incorporate a holistic design process.
 This design process describes all development steps needed to get from a problem description, via the set of features, to a finalized product.
 Furthermore, tooling to organize and test the development is required to utilize all advantages the \ac{ridm} provides.
--- a/front.pdf
+++ b/front.pdf
--- a/graphics/design_flow.tex
+++ b/graphics/design_flow.tex
@@ -1,31 +1,47 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
 \usetikzlibrary {arrows.meta,positioning}
 \tikzset{nodes={text height=.7em, text width=2.8cm, align=center,
 \usetikzlibrary {arrows.meta,positioning,calc,math}
 \tikzset{nodes={text height=.7em, text width=2.7cm, align=center,
 draw=black!50, thick, font=\footnotesize, fill=white},
 >={Stealth[round,sep]}, rounded corners, semithick}

 \pgfdeclarelayer{bg}
 \pgfsetlayers{bg,main}

 \begin{document}
 \begin{tikzpicture}[on grid,y=1.2cm,x=3.2cm]
    \draw[fill=lightgray] (-1.7cm , 0.5cm) rectangle (5cm, -2.8cm);
    \draw[fill=lightgray] (-1.7cm,-3cm) rectangle (5cm, -7.2cm);
 \begin{tikzpicture}[on grid,y=1.2cm,x=2.9cm]
 \def\rectoffset{-1.2mm,2.5mm};
 \def\rectoffsetleft{-2.90cm,0cm};
 \def\textoffset{2.9cm,0cm};
 \def\phasegroup(#1,#2,#3){%
    \begin{scope}[nodes={draw=none, fill=none,text height={}}]
        \coordinate (a) at ($(#1.north west)+(\rectoffset)$){};
        \coordinate (b) at ($(#2.south east)-(\rectoffset)-(\rectoffsetleft)$){};
        \draw[fill=lightgray] (a) rectangle (b);
        \node[anchor=center] at ($(#1)+(\textoffset)$) {#3};
    \end{scope}
    };
    \node (pd) {Problem Description};
    \node (sp)[below=1 of pd]  {Specifications};
    \node (sp)[below=1 of pd]  {Requirements};
    \node (id)[below=1 of sp]  {Initial Design};
    \node (fs)[below=1 of id]  {Feature Definition};
    \node (ss)[below=1 of fs]  {Feature Selection};
    \node (tp)[below=1 of fs]  {Test Protocol};
    \node (ss)[below=1 of tp]  {Feature Selection};
    \node (a1)[below=0.8 of ss,draw=none, fill=none] {};
    \node (rd)[below=0.8 of a1]  {Rapid Development};
    \node (va)[right=1 of a1]  {Variable Approach};
    \node (va)[right=1 of a1]  {Variable-detail Approach};
    \path[->] (pd) edge (sp)
              (sp) edge (id)
              (id) edge (fs)
              (fs) edge (ss)
              (fs) edge (tp)
              (tp) edge (ss)
              (ss) edge (rd)
              (rd.east) edge[bend right] (va)
              (va) edge[bend right] (ss.east);
    \draw (3.4cm,0cm) node[draw=none, fill=none,text width=2.9cm] (wf) {Systems Engineering:\\Waterfall};
    \node (ridm)[right=1 of fs, fill=none, draw=none] {Rapid Iterative Design Method};
    \begin{pgfonlayer}{bg}
        \phasegroup(pd,id,Systems Engineering);
        \phasegroup(fs,rd,Rapid Iterative Design Method);
    \end{pgfonlayer}
 \end{tikzpicture}
 \end{document}
--- a/graphics/design_flow_analysis.tex
+++ b/graphics/design_flow_analysis.tex
@@ -11,14 +11,14 @@ draw=black!50, thick, font=\footnotesize, fill=white},
    \draw[fill=lightgray] (-1.7cm, 1.5cm) rectangle (1.7cm, -5.3cm);
    \draw[fill=lightgray] (-1.7cm,-5.5cm) rectangle (5cm, -9.2cm);
    \node (pd) {Problem Description};
    \node (sp)[below=1 of pd]  {Specifications};
    \node (sp)[below=1 of pd]  {Requirements};
    \node (id)[below=1 of sp]  {Initial Design};
    \node (fs)[below=1 of id]  {Feature Definition};
    \node (tp)[below=1 of fs]  {Test Protocol};
    \node (ss)[below=1 of tp]  {Feature Selection};
    \node (a1)[below=0.8 of ss,draw=none, fill=none] {};
    \node (rd)[below=0.8 of a1]  {Rapid Development};
    \node (va)[right=1 of a1]  {Variable Approach};
    \node (va)[right=1 of a1]  {Variable-detail Approach};
    \node (pp)[above=0.8 of pd,draw=none,fill=none] {Preparation Phase};
    \node (dc)[below=1.6 of va,draw=none,fill=none] {Development Cycle};
    \path[->] (pd) edge (sp)
--- a/graphics/electronics.tex
+++ b/graphics/electronics.tex
@@ -11,7 +11,7 @@ draw=black!50, thick, font=\footnotesize, fill=white},
    \node (mc) {Micro Controller};
    \node (ha)[left=0.5 of mc,draw=none,fill=none]{};
    \node (hb)[right=0.5 of mc,draw=none,fill=none]{};
    \node (sc)[below=1 of hb] {Stepper Controller};
    \node (sc)[below=1 of hb] {Hardware Stepper Driver};
    \node (sm)[below=1 of sc] {Stepper Motor};
    \node (sv)[below=1 of ha] {Servo Motor};
    \path[->] (mc) edge (sc)
--- a/graphics/functional_relation.tex
+++ b/graphics/functional_relation.tex
@@ -2,20 +2,31 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
 \usetikzlibrary {arrows.meta,positioning}
 \usetikzlibrary {arrows.meta,positioning,calc,math}
 \tikzset{nodes={text height=.7em, text width=2.5cm, align=center,
 draw=black!50, thick, font=\footnotesize},
 draw=black!50, thick, font=\footnotesize, fill=white},
 >={Stealth[round,sep]}, rounded corners, semithick}
 \pgfdeclarelayer{bg}
 \pgfsetlayers{bg,main}

 \begin{document}
 \begin{tikzpicture}[on grid,y=2.2cm,x=5.7cm]
    \node (re) {Requirement};
    \node (fu)[right=1 of re]  {Function};
    \node (co)[above=1 of fu]  {Component};
    \begin{scope}[nodes={draw=none, fill=none, text width={},text height={}}]
    \node(c)[left=0.5 of co.north] {}; 
    \node(d)[above=2mm of c, anchor=south] {Elements of a Feature};
    \end{scope}
    \begin{scope}[nodes={draw=none, auto, fill=none, midway,text width={},text height={}}]
        \path[->] (re) edge node[below] {Specifies} (fu)
                  (co) edge node {Performs} (fu)
                  (re) edge node {Specifies} (co);
    \end{scope}
    \begin{pgfonlayer}{bg}
        \coordinate(a) at ($(re.south west) + (-2mm,-2mm)$);
        \coordinate(b) at ($(co.north east) + (2mm,2mm)$);
        \draw[fill=lightgray] (a) rectangle (b);
    \end{pgfonlayer}
 \end{tikzpicture}
 \end{document}
--- a/graphics/model_versions.tex
+++ b/graphics/model_versions.tex
@@ -2,7 +2,7 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
 \usetikzlibrary {arrows.meta,positioning,calc,math}
 \usetikzlibrary{arrows.meta,positioning,calc,math}
 \tikzset{nodes={text height=.6em, text width=2.5cm, align=center,
 draw=black!50, thick, font=\footnotesize, fill=white},
 >={Stealth[round,sep]}, rounded corners, semithick}
@@ -16,8 +16,8 @@ draw=black!50, thick, font=\footnotesize, fill=white},
 \def\textoffset{-2.5cm,0cm};
 \def\modelgroup(#1,#2,#3){%
    \begin{scope}[nodes={draw=none, fill=none,text width={},text height={}}]
        \node (a) at ($(#1.north west)+(\rectoffset)+(\rectoffsetleft)$){};
        \node (b) at ($(#2.south east)-(\rectoffset)$){};
        \coordinate (a) at ($(#1.north west)+(\rectoffset)+(\rectoffsetleft)$){};
        \coordinate (b) at ($(#2.south east)-(\rectoffset)$){};
        \draw[fill=lightgray] (a) rectangle (b);
        \node[anchor=center] at ($(#1)!0.5!(#2)+(\textoffset)$) {#3};
    \end{scope}
--- a/graphics/robmosys.tex
+++ b/graphics/robmosys.tex
@@ -11,7 +11,7 @@ draw=black!20, thick, fill=white, font=\footnotesize},
    \node (a) at (0,0) {Mission};
    \node (b) at (0,-1) {Task};
    \node (c) at (0,-2) {Skill};
    \node (d) at (0,-3) {Function};
    \node (d) at (0,-3) {Service};
    \node (e) at (0,-4) {Component};

    \begin{scope}[shift={(2.596cm,0)}]
--- a/graphics/robmosys_levels.tex
+++ b/graphics/robmosys_levels.tex
@@ -0,0 +1,24 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
 \usetikzlibrary {arrows.meta,positioning}

 \begin{document}

 \begin{tikzpicture}[on grid,y=1.5cm,x=2.24cm, nodes={text height=.7em, text width=1.8cm, align=center,
 draw=black!20, thick, fill=white, font=\footnotesize},
 >={Stealth[round,sep]}, rounded corners, semithick]
    \node (a) at (0,0) {Mission};
    \node (b) at (0,-1) {Task};
    \node (c) at (0,-2) {Skill};
    \node (d) at (0,-3) {Service};
    \node (e) at (0,-4) {Component};

    \path[->] 
    (a) edge (b)
    (b) edge (c)
    (c) edge (d);
    \path[->,dashed]
    (d) edge (e);
 \end{tikzpicture}
 \end{document}
--- a/graphics/scara_test.JPG
+++ b/graphics/scara_test.JPG
--- a/graphics/test_flow_graph.tex
+++ b/graphics/test_flow_graph.tex
@@ -14,11 +14,11 @@ draw=black!50, thick, fill=white, font=\footnotesize},
    block/.style={rectangle, minimum height=4em, text width=4em},
    cloud/.style ={draw=red, thick, ellipse,fill=red!20, minimum height=2em}]

    \node[block] (ft) {Failed Test};
    \node[block] (ft)[fill=lightgray] {Start:\\Failed Test};
    \node[decision] (pb)[below = 1 of ft] {Passed Before?};
    \node[decision] (ep)[below = 1 of pb] {Expected to pass?};
    \node[decision] (ef)[right = 1 of pb] {Expected to fail?};
    \node[block]  (cont)[below = 1 of ef] {Continue};
    \node[block]  (cont)[below = 1 of ef] {Continue, add next detail};
    \node[decision] (fu)[right = 1 of cont] {Will pass in future?};
    \node[block]   (res)[below = 0.8 of cont] {Review Design};
    \begin{scope}[nodes={draw=none, fill=none, midway,text width={}}]
--- a/graphics/time_table.tex
+++ b/graphics/time_table.tex
@@ -13,21 +13,23 @@
    xmin=0,
    xmax=21,
    width=85mm,
    height=75mm,
    height=80mm,
    enlarge y limits=0.15,
    legend style={at={(0.98,0.95)},
        anchor=north east,legend columns=-1},
    xlabel={Days},
    symbolic y coords={Software Development,Development Cycle 2,Development Cycle 1,Test Protocol,Feature Definition,Initial Design,Specifications,Problem Description},
    symbolic y coords={Software Development,Hardware Construction,Development Cycle 2,Development Cycle 1,Test Protocol,Feature Definition,Initial Design,Specifications,Problem Description},
    ytick=data,
 ]
    \addplot[draw=red,fill=red!40] coordinates {(2,Problem Description) (3,Specifications) (3.5,Initial Design) (13,Feature Definition) (0.5,Test Protocol) (3,Development Cycle 1) (17,Development Cycle 2) (20,Software Development)};
    \addplot[draw=blue,fill=blue!40] coordinates {(2,Problem Description) (3,Specifications) (5,Initial Design) (6,Feature Definition) (1,Test Protocol) (3,Development Cycle 1) (13,Development Cycle 2)};
    \addplot[draw=red,fill=red!40] coordinates {(2,Problem Description) (3,Specifications) (3.5,Initial Design) (2.5,Feature Definition) (0.5,Test Protocol) (3,Development Cycle 1) (14,Development Cycle 2) (2,Hardware Construction) (20,Software Development)};
    \addplot[draw=blue,fill=blue!40] coordinates {(2,Problem Description) (3,Specifications) (5,Initial Design) (5,Feature Definition) (1,Test Protocol) (3,Development Cycle 1) (11,Development Cycle 2)};
    \legend{Time Spend,Time Planned};
    \pgfmathsetlengthmacro{\baroffset}{\barwidthvalue+\xbarvalue/2}
    \pgfmathsetlengthmacro{\smeer}{7mm}
    \node (a) at ($(axis cs:3,Development Cycle 1)-(0.1mm,0mm)+(0mm,\baroffset)$) {};
    \node (b) at ($(axis cs:3,Development Cycle 1)-(0.1mm,0mm)-(0mm,\baroffset)$) {};
    \pgfmathsetlengthmacro{\superscriptoffset}{8.5mm}
    \node (d) at ($(axis cs:3,Development Cycle 1)+(\superscriptoffset,1mm)$) {\textsuperscript{2}};
    \coordinate (a) at ($(axis cs:3,Development Cycle 1)-(0.1mm,0mm)+(0mm,\baroffset)$);
    \coordinate (b) at ($(axis cs:3,Development Cycle 1)-(0.1mm,0mm)-(0mm,\baroffset)$);
    \fill[white] (a) rectangle ++(\smeer,-\barwidthvalue-1mm);
    \fill[red!40,path fading=east] (b) rectangle ++(\smeer,1mm);
    \fill[blue!40,path fading=east] (a) rectangle ++(\smeer,-\barwidthvalue);
@@ -35,6 +37,13 @@
    \draw[white] ($(b)$) -- +(\smeer,0mm); 
    \draw[blue,path fading=east] ($(a)$) -- +(\smeer,0mm) ++(0mm,-\barwidthvalue) -- +(\smeer,0mm);
    \draw[red,path fading=east] ($(b)$) -- +(\smeer,0mm); 
    
    \node (e) at ($(axis cs:3,Feature Definition)+(\superscriptoffset,1mm)$) {\textsuperscript{1}};
    \coordinate (c) at ($(axis cs:2.5,Feature Definition)-(0.1mm,0mm)-(0mm,\baroffset)$);
    \fill[red!40,path fading=east] (c) rectangle ++(\smeer,1mm);
    \draw[white] ($(c)$) -- +(\smeer,0mm); 
    \draw[red,path fading=east] ($(c)$) -- +(\smeer,0mm); 
    \draw[blue,path fading=east] ($(c)+(0pt,1mm)$) -- +(\smeer,0mm);% ++(0mm,-\barwidthvalue) -- +(\smeer,0mm);
 \end{axis}
 \end{tikzpicture}
 \end{document}
--- a/graphics/waterfall.tex
+++ b/graphics/waterfall.tex
@@ -1,23 +0,0 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
 \usetikzlibrary {arrows.meta,positioning}
 \tikzset{nodes={text height=.7em, text width=2.8cm, align=center,
 draw=black!50, thick, font=\footnotesize, fill=white},
 >={Stealth[round,sep]}, rounded corners, semithick}

 \begin{document}

 \begin{tikzpicture}[on grid,y=1.2cm,x=3.2cm]
    \node (pd) {Problem Description};
    \node (sp)[below=1 of pd]  {Specifications};
    \node (id)[below=1 of sp]  {Initial Design};
    \node (im)[below=1 of id]  {Implementation};
    \node (te)[below=1 of im]  {Testing};
    \path[->] (pd) edge (sp)
              (sp) edge (id)
              (id) edge (im)
              (im) edge (te);
 \end{tikzpicture}
 \end{document}

--- a/include
+++ b/include
@@ -1 +1 @@
 Subproject commit c60fc733267eb72f37dc3228cf76d95be5a7d7db
 Subproject commit 3992363ddc1bcff510a52dfcab9e814c5986575e
--- a/report.tex
+++ b/report.tex
@@ -1,9 +1,8 @@
 \documentclass[english,titlepage,nomath,nopackage,oneside]{siltex-book}
 \include{include/preamble}
 \usepackage{pdfpages}

 \newcommand{\ridm}{\ac{ridm} }

 \title{Title}
 \title{}
 \subtitle{Thesis Report}
 \course{}
 \faculty{\large Electrical Engineering, Mathematics and Computer Science}
@@ -15,16 +14,14 @@
    Wouter Horlings
 }



 \begin{document}
 \maketitle
 \includepdf{front}
 \frontmatter
 \include{include/acronyms}
 \input{samenvatting}
 \input{summary}
 \tableofcontents

 \acresetall
 \mainmatter
 \input{introduction}
 \input{background}