Rework content

content/case_experiment_feature_definition.tex

@@ -1,46 +1,61 @@
 %&tex
-    \subsection{Feature Definition}
-                \label{sec:case_featuredefinition}
-            At this point there are specifications and an initial design for the system.
-            In the following steps of the design method features will be implemented one by one.
-            The goal of this step is then to define these features.
-            During this step it became clear that this approach was not feasible.
-            Prior to this step the expectation was that this step would produce three features that could be implemented.
-            These three features were the SCARA, the cable suspended carriage, and the end-effector.
-            However, independent of the interpretation of this step, the result was not the three expected features.
+\subsection{Feature Definition}
+    \label{sec:case_featuredefinition}
+    At this point there are specifications and an initial design for the system.
+    In the following steps of the design method features will be implemented one by one.
+    The goal of this step is to define those features.
+    However, the predefined approach was not able to produces a set of features that could be implemented.
+    This forced me to create a new approach for this step, introducing components into the design.
+    This section will first address why the current approach is not suitable, followed by the alternative approach.
 
-            Why were those three features expected in the first place?
-            During the previous steps a useful evaluation was to anticipate for the subsequent steps.
-            Where one of the following steps is to implement an individual feature.
-            Therefore, it must be possible to implement the feature.
-            Separating the initial design into the smallest components that could still be implemented, resulted in the SCARA, carriage and end-effector.
+    \subsubsection{Struggles with Features}
+        For their case study, \textcite{broenink_rapid_2019} design a control system for a mini-segway.
+        This mini-segway is an already existing \ac{cps} that is used during the lab-sessions of a control course, and any control-law can be uploaded directly to the system.
+        The specified features of that system are defined as:
+        \begin{enumerate}
+            \item Balancing the mini-segway upright
+            \item Steering the mini-segway
+            \item Driving forward and backward
+        \end{enumerate}
+        Although this is not explicitly explained, these features have dependencies: the steering and the driving both rely on a balanced segway.
 
-            The problem is that these three components do not describe the complete system.
-            Some functions of the system (feature) is performed by a combination of the components.
-            Therefore can the components in the system not be seen as features of the system.
-            Defining the components as features of the system is not a solution.
-            The relations between the components and features is still required.
+        A set of features for the Whiteboard writer would be:
+        \begin{enumerate}
+            \item Write character on position
+            \item Move carriage to position
+            \item Write text
+        \end{enumerate}
+        In this case, features 1 and 2 are required for feature 3.
+        However, in contrast with the mini-segway, the whiteboard writer does not exist yet.
+        Instead of creating a model based on the system, the system has to be designed first.
+        For these three features, the required hardware can be designed together with the feature.
+        The first feature would then also contain the design of the SCARA and the second feature the cable bot design.
+        Adding the features needed to meet the specifications for wiping the whiteboard, then such a feature would also need to design the SCARA.
+        In other words, more than one feature uses the SCARA in their behavior.
+        Resulting in the question: which feature should implement the hardware?
 
-            %As the features describe the behavior of the components, it is not a solution to replace the features with components.
+    \subsubsection{Separating Functions and Components}
+        It was decided not to add the SCARA and the cable bot as features, for the reason that they do not define behavior.
+        Instead, the features define how the hardware behaves.
+        A solution to organize the relations between features and components was found in RobMoSys\footnote{\url{https://robmosys.eu/approach/}}.
+        RobMoSys defines a separation of levels in a design.
+        Where the levels start functional and moves via software to hardware implementation.
+        Although not all levels of RobMoSys are used, it was very useful to define the features of the system.
+        The definition is shown in \autoref{fig:robmosys}.
+        The current definition of features allows to start the implementation with a component.
+        When the component is finished features can be implemented by following the tree upwards.
+        \begin{figure*}
+            \centering
+            \includegraphics[width=0.85\linewidth]{graphics/robmosys}
+            \caption{Feature Definition based on the separation of levels introduced by RobMoSys}
+            \label{fig:robmosys}
+        \end{figure*}
 
-            A solution to organize the relations between features and components was found in RobMoSys\footnote{\url{https://robmosys.eu/approach/}}.
-            RobMoSys defines a separation of levels in a design.
-            Where the levels start functional and moves via software to hardware implementation.
-            Although not all levels of RobMoSys are used, it was very useful to define the features of the system.
-            The definition can be seen in \autoref{fig:robmosys}
-            The current definition of features allows to start the implementation with a component.
-            When the component is finished features can be implemented by following the tree upwards.
-            \begin{figure*}
-                \centering
-                \includegraphics[width=0.85\linewidth]{graphics/robmosys}
-                \caption{Feature Definition based on the separation of levels introduced by RobMoSys}
-                \label{fig:robmosys}
-            \end{figure*}
 
-            \subsubsection{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 really strong border 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}
+        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 really strong border 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.