From f2eb24d3e5cc4cce45acd29a923d8ce4130758b0 Mon Sep 17 00:00:00 2001 From: Wouter Horlings Date: Wed, 9 Dec 2020 17:37:05 +0100 Subject: [PATCH] Rework content --- .../case_experiment_feature_definition.tex | 96 +++++++++++-------- content/case_experiment_initial_design.tex | 1 + 2 files changed, 56 insertions(+), 41 deletions(-) diff --git a/content/case_experiment_feature_definition.tex b/content/case_experiment_feature_definition.tex index c3fc5ec..314a004 100644 --- a/content/case_experiment_feature_definition.tex +++ b/content/case_experiment_feature_definition.tex @@ -1,46 +1,60 @@ %&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 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. diff --git a/content/case_experiment_initial_design.tex b/content/case_experiment_initial_design.tex index 3630936..7b95523 100644 --- a/content/case_experiment_initial_design.tex +++ b/content/case_experiment_initial_design.tex @@ -1,5 +1,6 @@ %&tex \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.