%&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 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.

    \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.

        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?

    \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 \autocite{noauthor_robmosys_2017}.
        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*}

    \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.