Add feedback Tim

4 年之前 · 96c6e1f83e
--- a/content/analysis.tex
+++ b/content/analysis.tex
@@ -7,7 +7,7 @@ The goal is to have 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 steps that are introduced by \ac{ridm} are covered in more detail.

 \section{Systems Engineering}
    The goal of the preliminary design is to setup system requirements and an initial design according to the problem definition.
@@ -47,16 +47,16 @@ The steps that are introduced by \ridm are covered in more detail.
        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.
    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 \ridm as explained in \autoref{chap:background}, the next step is the feature selection.
    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 specifications.
    Following the \ridm, these tests are specified at the start of the rapid development cycle.
    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.

@@ -66,35 +66,130 @@ The steps that are introduced by \ridm are covered in more detail.
    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.
    From this point, the \ac{ridm} is repeated from the third step until all features are implemented.

 \subsection{Feature Definition}
 \subsection{Define features of the design}
    \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.
    During the feature definition step, the system is split into features as preparation for the rapid development cycle and the variable-detail approach.
 %
 %    \subsubsection{Functions and Components}
 %        \textcite{broenink_rapid_2019} define the features of their system by dividing the functionality of the system.
 %        However, the design method in this thesis also includes the development of the hardware.
 %        This creates an extra dimension to the features in the design.
 %        In addition of splitting the functionality, the hardware has to be split as well.
 %        Therefore, the design is described with two types of features.
 %        The functionality is split into functions and the hardware is split in to components.
 %
 %    \subsubsection{Making the Cut}
        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.
        Resulting in short development cycles and earlier feedback about the design.
        The approach in this design plan aims to provide more guided and structured way to split the features.
        \begin{marginfigure}
            \centering
            \includegraphics[width=21mm]{graphics/robmosys_levels.pdf}
            \caption{}
            \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}, serving coffee for example.
        Followed by less abstract levels such as: a \emph{task} to fill the coffee mug; a \emph{skill} to hold the coffee mug; and a \emph{service} that opens or closes the hand.

    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.
        The different levels allow the features to be split multiple times in a structured way.
        Take the coffee serve 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}.

    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. 
        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 kind of milestone, at the moment that relevant \emph{services} are combined.
        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 two or more \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, but still needs 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 the hardware instead of functionality.
        The components are used to perform 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}
@@ -236,10 +331,10 @@ In the case that this is the last feature to implement, this concludes the devel
 \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{ridm} and the Waterfall model.}
    \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 waterfall model from \ac{se} and the \ac{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 last step of the preparation is the feature definition, where the initial design is split into different features.
--- a/content/case_experiment_feature_definition.tex
+++ b/content/case_experiment_feature_definition.tex
@@ -3,49 +3,68 @@
    \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.
    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.
        If each feature would have been split methodically, the amount of features would be immense.

    \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 could 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/conclusion.tex
+++ b/content/conclusion.tex
@@ -1,4 +1,18 @@
 %&tex
 %    \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}.
 %    \end{itemize}
 %    Based on the results of the case study I will answer the following research questions:
 %    \begin{itemize}
 %        \item Which techniques of the \ac{ridm} can be applied developing the physical part of \ac{cps}?
 %        \item Which adaptations are required to make the \ac{ridm} suitable for developing the computation and physical part of \ac{cps}?
 %    \end{itemize}



 \chapter{Conclusion}
 \label{chap:conclusion}
 % Intro: end goal
@@ -19,33 +33,94 @@ Furthermore, a feature selection step is added to aid with the development.
 The third and last research objective is to develop and perform a case study that tests and evaluates the design plan.
 The case study consists of a development that is performed according to the design plan.
 A set of requirements is made to ensure the optimal system of design.
 With this the \ac{Tweet on a Writeboard} system is chosen.
 With this the \emph{Tweet on a Writeboard} system is chosen.
 The progress of the case study is monitored according to a list of questions.


 % Answer:  Which design techniques of the design method by Broenink and Broenink (2019) can be applied developing the physical part of CPS?
 With three research objectives fulfilled, it is possible to answer the two research questions:\\
 \emph{Which design techniques of the \ac{ridm} can be applied developing the physical part of CPS?}\\
 \emph{Which techniques of the \ac{ridm} can be applied developing the physical part of CPS?}\\

 To answer this question I must put emphasis on the difference between the design and modelling process.
 The design process embodies the development of a product or system as an answer to a problem or need.
 The modelling process allows the developers to gain insight of the inner workings of a product.
 By creating and simulating models for the system under design, the modelling process improves the design process tremendously.
 Looking at the \ac{ridm}, the fact that the first research objective is to prepend design steps to the \ac{ridm} highlights its shortcoming as a design method.

 Despite its exploratory nature, the case study offers some insight into the \ac{ridm} as a technique for rapid prototyping.
 The segmentation of the design provides a structured and organized approach.
 Moreover, the in this thesis proposed feature selection procedure contribute to the risk management of the development.
 By implementing high risk-per-time features first, the design problems are more likely to be found in the early stage of the design.

 The variable-detail approach is promising for the implementation of individual features.
 Similar to the design begin split in features, this approach implements one feature as multiple levels of detail.
 One benefit is that the structured addition of detail enables intermediate testing, allowing the development to continue when all tests are satisfied.
 Another benefit is that having one model available in different level of detail is that these models can be reused with the minimum detail possible.
 This keeps the complexity of models to a minimum and can be useful to improve simulation speed of large systems.
 The major limitation in this thesis is that the model represented the design.
 Therefore, the stopping at a certain level of detail or reusing lower detail models did not occur during the case study.
 Notwithstanding these limitations, the variable-detail approach does offer a structured approach providing feedback during the implementation.

 \emph{Which adaptations are required to make the \ac{ridm} suitable for developing the computation and physical part of CPS?}\\
 The most obvious finding to emerge from this study is that the \ac{ridm} without any additions is not a valid design method.
 The findings of the case study suggest that a worthwhile solution is to make \ac{ridm} part of a existing design method.
 The existing method provides a basis wherein the \ac{ridm} can come to its own, which is to tackle complexity.


 To answer this question I must put emphasis on the difference between the design and the model.
 The design is the specification of a system, it contains the plans, drawings, documentation, etc.
 A model represent portions of that design, depending on the goal purpose of the model.
 Both methods, from this thesis and the \ac{ridm}, make no adequate distinction between the design and the model.
 As the case study by \autocite{broenink_rapid_2019} is performed with existing hardware, the design is already finished.
 This highlights the shortcoming of the \ac{ridm} as it does model, and not design a system.

 The method in this thesis introduces additional steps to implement the design process.
 Although an initial design is produced, the design is implemented as a model.
 %This thesis was designed to assess whether the physical part of \ac{cps} can be developed using the \ac{ridm}.
 %Whereby the \ac{ridm} aims to reduce the complexity of a system design.
 %The requirement for the case study was to develop a system with sufficient complexity, to apply the \ac{ridm} as intended.
 %Being focused on the physical part of the design, this thesis overlooks the significance of software in a \ac{cps}.
 %Especially because the complexity of a system is made possible with software.
 %
 %A design method regarding the full life cycle of \ac{cps}, must therefore incorporate both the computation and physical part of \ac{cps}.
 %To use the advantages of the \ac{ridm} in such a design method, there must be a clear distinction between the functions, requirements and components.
 %Where possibly each of these three require a different design approach.

 The point is, the design and the model are two separate components of the design process.
 The fact that this thesis starts with adding half a \ac{se} approach shows that the design aspect lacks in the current method.
 However, both case studies suggest that the \ac{ridm} is a good approach for implementing that design.

 This brings me to the last questions:\\
 \emph{Which adaptations are required to make the design method by \ac{ridm} suitable for developing the computation and physical part of CPS?}\\
 It is clear that there has to be a design process added, which must implement the different elements of a feature: component, function, requirement.




 %The explicit focus on physical part in the design process, caused a neglect toward the computation part of a \ac{cps}.
 %
 %The design is the specification of a system, it contains the plans, drawings, documentation, etc.
 %A model represent portions of that design, depending on the goal purpose of the model.
 %Both methods, from this thesis and the \ac{ridm}, make no adequate distinction between the design and the model.
 %As the case study by \autocite{broenink_rapid_2019} is performed with existing hardware, the design is already finished.
 %This highlights the shortcoming of the \ac{ridm} as it does model, and not design a system.
 %
 %The method in this thesis introduces additional steps to implement the design process.
 %Although an initial design is produced, the design is implemented as a model.
 %
 %The point is, the design and the model are two separate components of the design process.
 %The fact that this thesis starts with adding half a \ac{se} approach shows that the design aspect lacks in the current method.
 %However, both case studies suggest that the \ac{ridm} is a good approach for implementing that design.
 %
 %This brings me to the last questions:\\
 %It is clear that there has to be a design process added, which must implement the different elements of a feature: component, function, requirement.

 % Answer: Which adaptations are required to make the design method by Broenink and Broenink (2019) suitable for developing the computation and physical part of CPS?

 \section{Recommendations}

 \begin{itemize}
    \item To use the variable-detail approach in an optimal way, there are two issues that must be addressed.
        The first one is the continuous testing of dynamic models.
        In a similar approach to unit testing in software, it must be possible to apply changes to a model and check whether everything still works as expected.
        A big issue here is the two-port behavior of dynamic models in comparison with software functions.
        When a software function is called with given parameters, it returns a specific result.
        This result is independent of the program this function is part of.
        In contrary, a dynamic model is not independent.
        The step response of a electro motor is significantly different if a fly-wheel is attached or not.
        Unit testing on sub-models in a dynamic model is therefore not reliable, making intermediate testing of the model difficult.
        The second issue is the organization of model versions.
        The benefit of switching between different sub-models is discussed in this thesis.
        However, switching between different detail versions is difficult and labor intensive.
 \end{itemize}



        

--- a/content/introduction.tex
+++ b/content/introduction.tex
@@ -34,13 +34,13 @@
    \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 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}.
    \end{itemize}
    Based on the results of the case study I will answer the following research questions:
    \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 Which techniques of the \ac{ridm} can be applied developing the physical part of \ac{cps}?
        \item Which adaptations are required to make the \ac{ridm} suitable for developing the computation and physical part of \ac{cps}?
    \end{itemize}

 \section{Approach}
--- 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/include
+++ b/include
@@ -1 +1 @@
 Subproject commit c60fc733267eb72f37dc3228cf76d95be5a7d7db
 Subproject commit 9bd73b3e58472c35df2903bfde1dd4c766dad018