\chapter{Concept}
\label{ch:Concept}

In this chapter definitions from \autoref{ch:Foundations} are extended, requirements formulated and assumptions made. Later, user interaction with the recommender system is described and the case study presented. Moreover, the process of generating recommendations is formulated and described. Last, the concept is illustrated using an example.

\section{Foundations Extension}
\label{sec:Concept:Requirements}

The definitions described in \autoref{ch:Foundations} need to be extended for this thesis. This section adds definitions that are required.

\subsection{Configuration State}

A \emph{configuration} $S$ will be defined as a tuple of variables (\autoref{eq:Foundations:ProductConfiguration:Variables}) and their corresponding domain value with
\begin{equation} \label{eq:Foundations:ProductConfiguration:ConfigurationState}
    S = \{ (v_i,\ d) \ |\ v_i \in V \ \land \ d \in \mathfrak{D}(i),\ i=1,\dotsc,m \}.
\end{equation}
Essentially it is a set of variables and assigned values.

\subsection{Finished Configuration}
To define what a \emph{finished configuration} is, it is necessary to first define what it means for a configuration to be valid. Therefore $is\_valid$ is defined as
\begin{equation} \label{eq:Foundations:ProductConfiguration:IsValid}
    is\_valid : S \to \{true, false\}; x \mapsto 
    \begin{cases}
        true, & S \in solution\_space \\
        false, & \text{otherwise}
    \end{cases},
\end{equation}
with $solution\_space$ being the solution space of the corresponding constraint satisfaction problem. A \emph{finished configuration} $S_F$ is a configuration that contains all variables and is a valid configuration:
\begin{equation} \label{eq:Foundations:ProductConfiguration:FinishedConfiguration}
    S_F \subset S,\ where \ \forall v_i \in V (\exists (v_i, d) \in S_F : d \in \mathfrak{D}(i)) \land is\_valid(S_F).
\end{equation}
In practice, a finished configuration of a product is something that is ready to be produced. For example if a car is being configured, this means that the car can be produced in the specified way given by the finished configuration.


\subsection{Group-Based Product Configuration}
\label{sec:Foundations:GroupBasedProductConfiguration}

Instead of a single person configuring a product, a group of people configures one product which can be useful in multi-stakeholder decisions. This setting needs mechanisms for describing the preferences of multiple people. Therefore, a set of users $U$ will be introduced with
\begin{equation}\label{eq:Foundations:ProductConfiguration:Users}
    U = \{1, \dotsc, n\},
\end{equation}
and a user's \emph{utility function} that maps a domain value to a utility value and is only known to the user
\begin{equation}
    \begin{split}
        u_i(d_j), \qquad \text{where}\ & u_i(d_j) \in [0,1] \\
        & d_j \in  \mathfrak{D}(j),\\
        & 1 <= j <= m, \\
        & 1 <= i <= n.
    \end{split}
\end{equation}

\subsection{Group Recommender}

For a group recommender system additional definitions are required. The attitude of users is represented by their preferences $P$ which are directly related to how the user benefits from a domain value being present in the configuration. Let 
\begin{gather} \label{tab:Foundations:GroupRecommenderSystem:Preferences}
    P = \{ P_1, \dotsc, P_n\},\ \text{where} \\
    P_i = \{(d,\ u_i(d)) \ | \ \forall d \in \mathfrak{D}(i),\ i=1,\dotsc,m \} \notag
\end{gather}


\section{Requirements}
\label{sec:Concept:Requirements}

This section lists requirements that are considered and implemented in this thesis by the group-based configurator, including the recommendation system.

\begin{itemize}
    \item Mandatory:
        \begin{itemize}
            \item The recommender should support a continuous value range for preferences
            \item The recommendation engine can be used without proprietary software.
            \item Give recommendations to a group, based on their preferences and the current configuration state.
            \item The system supports multiple group configurators at the same time.
            \item The system should take the current configuration state into account.

            \item Recommendations should always be valid solutions.
            \item The system has to respond in a timely manner.
        \end{itemize}
    \item Optional:
        \begin{itemize}
            \item Provide a simple user interface.
            \item The system should be able to work with other configuration systems.
            \item Recommendations should allow different scoring functions.
        \end{itemize}
\end{itemize}


\section{Assumptions}
\label{sec:Concept:Assumptions}

Due to the fact that a thesis has limited resources, some assumptions have to be made. The assumptions made are listed in this section.

\begin{itemize}
    \item Only one product/solution is supposed to be configured at the same time by one group.
    \item Features only support single value attributes.
    \item Users join the system and start configuring only after all group members have joined.
    \item Speed and optimization of the system does not have high priority.
    \item The user interface is for demo purposes.
\end{itemize}
In order to reduce complexity, the assumptions are made that only single value attributes are supported and one product is configured at a time by a group. Therefore, less implementation work is needed. However, results are not dependent on these implementations. Most features use only single value attributes. It is also possible to model a feature that supports multiple attributes. As an example the feature \emph{audio system} has the following options: \emph{Bluetooth} or \emph{CD}. To allow multiple attributes to be selected the characteristics \emph{Bluetooth and CD} can be added.
The assumption that users join the system and only start configuring once all members of the group joined is made to reduce the amount of work needed for creating a lobby and waiting system which is not relevant for showing the functionality of the recommender. Speed and optimization of the system having no high priority as the speed has no influence on the results of this thesis. Therefore, as long as the system is fast enough, no further optimisation of speed is needed.
The evaluation is done solely with the recommender system and its APIs. Thus, the user interface is not directly relevant for the evaluation but it is relevant for communication of results.

\section{User Interaction with the System}
\label{sec:Concept:UserSystemInteraction}

There is one main way to use the system which is defined in \autoref{tab:Concept:MainUseCase}. This process is also visualized in \autoref{fig:Concept:ConfigurationProcess}. All users start the configuration process together.
They select the current state at the beginning of the process. Then users repeatedly enter their preferences until each user's preferences have been entered into the system. Based on the entered preferences the system generates a recommendation that is a compromise of all users preferences.

\begin{figure}
    \centering
    \includegraphics[width=1\textwidth]{./figures/40_concept/bpmn_configuration_process_with_continious_recommendation.pdf}
    \caption{A BPMN diagram of the configuration process.}
    \label{fig:Concept:ConfigurationProcess}
\end{figure}

\begin{table}
    \begin{center}
        \begin{tabularx}{\columnwidth}{l|X}
            \multicolumn{2}{c}{Main System Usage} \\
            \hline
            Preconditions   & 
                \begin{itemize}
                    \item The configurator is opened with the same session on each of the group member's machines
                    \item The configuration is in an unfinished state (this state is a consensus state)
                \end{itemize} \\
            \hline
            Postcondition   & 
                \begin{itemize}
                    \item All users have entered their preferences for each attribute explicitly.
                    \item The system gives a recommendation based on all preferences and the unfinished configuration state
                \end{itemize} \\
            \hline
            Basic Flow      & 
                \begin{enumerate}
                    \item A user indicates a preference for an attribute
                    \item The system generates a recommendation (based on preferences and configuration status)
                    \item If not all users have given their preferences go to step 1.
                \end{enumerate} \\
            \hline
        \end{tabularx}
        \caption{A description of the main way users will interact with the system}
        \label{tab:Concept:MainUseCase}
    \end{center}
\end{table}

\section{Case Study}
\label{sec:Concept:CaseStudy}

The case study used in this thesis is a simplified version from forestry \todo[]{hier evtl ergänzen: wo kommt der Use Case her / aus welchem Forschungsprojekt / warum ist er interessant?}.
The used characteristics and attributes are shown in \autoref{fig:Concept:ForestExample}. Additionally, as examples preferences, a configuration state and a finished configuration are given.

\begin{figure}
    \begin{mdframed}[frametitle={Example for Forest Use Case}, linecolor=black, frametitlerulecolor=black, frametitlebackgroundcolor=gray!5]
        In this example there is a small group of users. The use case is a piece of forest and variables are for example harvesting activity, which trees to grow and accessibility for people.
        \begin{align}
            \begin{split}
                V = \{ & \textit{indigenous}, \textit{resilient}, \textit{usable}, \textit{effort}, \textit{quantity}, \textit{price}, \textit{accessibility} \},
            \end{split} \notag \\
            \mathfrak{D}(\textit{indigenous}) =  \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
            \mathfrak{D}(\textit{resilient}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
            \mathfrak{D}(\textit{usable}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
            \mathfrak{D}(\textit{effort}) = \{ & \text{manual}, \text{harvester}, \text{autonomous}\}, \notag \\
            \mathfrak{D}(\textit{quantity}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
            \mathfrak{D}(\textit{price}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag\\
            \mathfrak{D}(\textit{accessibility}) = \{ & \text{low}, \text{moderate}, \text{high}\},\notag \\
            U = \{ & 1,2\} \notag\\
            P = \{ & P_1, P_2\} \notag\\
            \begin{split}
                P_1 = \{ & (\text{manual}, 0.8), (\text{harvester}, 0.3) \} \\ 
                & \cup \{ (d,0.5)\ |\ d \in \mathfrak{D}(i),\ i \in V,\ i \notin \{ \text{manual}, \text{harvester}\} \ \} \ 
            \end{split} \notag \\
            P_2 = \{ & (d,0.5)\ |\ d \in \mathfrak{D}(i),\ i \in V \} \notag \\
            S  =  \{ & (\textit{indigenous}, \text{low}), (\textit{quantity}, \text{moderate}) \} \notag \\
            \begin{split}
            S_F  =  \{ & (\textit{indigenous}, \text{low}), (\textit{resilient}, \text{low}), (\textit{usable},\text{low}), (\textit{effort}, \text{manual}), \\
            & (\textit{quantity}, \text{low}), (\textit{price},\text{high}),(\textit{accessibility}, \text{low}) \} 
            \end{split} \notag
        \end{align}
    \end{mdframed}
    \caption{An example of a forest use case that includes two people.}
    \label{fig:Concept:ForestExample}
\end{figure}


\section{Recommendation Generation}
\label{sec:Concept:SolutionGeneration}

This section describes how recommendations are generated. The recommender system has a database that stores possible finished configurations and the goal is to rank these recommendations according to a scoring function and to recommend the best possible configuration. The scoring function is referred to as the \emph{group configuration scoring function}. It uses the current configuration state, the preferences of the group and a finished configuration to calculate a score. This score resembles how good this configuration resembles the interest of the group. The exact procedure looks as follows:

\begin{enumerate}
    \item Assign a score to each stored configuration according to $$score_{group}(\overline{configurationState},\ \overline{preferences}, \ configurationInStore)$$
    \item Chose the configuration with the highest score as recommendation.
\end{enumerate}

It is optionally possible to have multiple runs with different scoring functions. This, for example, allows the removal of configurations that cause a lot of misery.



\subsection{Scoring Function}

\label{subsec:Concept:SolutionGeneration:ScoringFunction}

The \emph{group configuration scoring function} includes preferences and current configuration state. This function gives a score for a finished configuration (while using the current configuration state and all user preferences):
\begin{equation}
    score_{group}: S \times P \times S_F \to \mathbb{R}
\end{equation}

An example group configuration scoring function is $score_{group}$ with
\begin{equation}
    score_{group}(\overline{s},\ \overline{p},\ s) = score(\overline{p},\ s) \cdot penalty(\overline{s},\ s)
\end{equation} 

This thesis will use multiple scoring functions. Among those are ones for least misery, average and multiplicative which all are implemented by $score$ (see \autoref{subsec:Concept:ReccomendationGeneration:PreferenceScoring} and \autoref{subsec:Concept:ReccomendationGeneration:Penalty}). Average and multiplicative yield good results among the studies presented by \citeauthor{Masthoff2015} \cite{Masthoff2015}. Strategies can also be combined, one example here is average without misery. The scoring functions used for this thesis all combine $penalty$ and $score$ by multiplication. However it is possible to use other combination strategies and it is possible to combine multiple scoring functions into one group scoring function. This thesis will use simpler scoring functions that are not combined but improvement here is possible.

\subsection{Preference Scoring}
\label{subsec:Concept:ReccomendationGeneration:PreferenceScoring}

All of the aggregation functions mentioned in \autoref{subsec:Concept:SolutionGeneration:ScoringFunction} have one preference per product. For configuration where a preference for all characterises exists there needs to be a function that combines the preferences of one user into her configuration score. After one score has been calculated per user the mentioned preference aggregation strategies can be used.

A simple scoring function approach is to use the the preference for each characteristic that is part of the configuration and then use the average. This approach is transparent because the preference of a user is directly translated into the score and no weighting is done. It means that a configuration score is simple to understand and to calculate. However, if needed, for example, to give one group member more power, it allows relative weighting. This can be done with preprocessing of preferences. Moreover, an approach like this ensures that through preprocessing feature weights can be added. It is therefore possible that a user gives different importances to features. Also, other means of weighting ratings are possible. For example the ratings of one group member who has more knowledge in an area can be increased by multiplication with a factor or alternatively the preferences for all other users can be decreased.
The formula for this rating function looks as follows:

\begin{equation}
    score(\overline{p},\ s) = aggr( \ \{score_{user}(P_i, s) \ | \ P_i \in \overline{p} \} \ )
\end{equation}
where $aggr$ the aggregation function and $score_{user}(P_i, s)$ the configuration score of user $i$ which is defined as
\begin{equation}
    score_{user}(P_i, s) = average(\{x \ | \ (characteristic, x) \in P_i \land characteristic \in s \}) \notag . 
\end{equation}

The example in \autoref{fig:Concept:ForestExample} contains two users. The first user has preferences for the characteristic \emph{manual} of the feature with $0.8$ and the characteristic \emph{harvester} of the same feature with $0.3$. All other characteristics have a preference of $0.5$. The second user's preferences are $0.5$ for all characteristics. The finished configuration that is supposed to be rated in this example contains the characteristics \emph{low} for each feature except for \emph{effort} and \emph{quantity} which are set to \emph{manual} and \emph{high}. The score fore the finished configuration $S_F$ of user one is $0.54$. This score is the average of all seven features. User one rates all characteristics of all features as $0.5$ except two characteristics for \emph{effort}. Therefore all, feature scores for this user are $0.5$ except the score for \emph{effort} is $0.8$ because of the user's preference of $0.8$ for the characteristic \emph{manual}. The resulting average score per feature of $0.54$ is the user's score for this configuration. User two rates all characteristics with $0.5$ therefore the resulting average is $0.5$.
The group configuration score is dependent on the used aggregation strategy. Multiplication results in a score of $0.54 \cdot 0.5 = 0.27$. The score for average is $\frac{1}{2}(0.54 + 0.5) = 0.52$ and for least misery $\min \{0.54, 0.5\} = 0.5$.

\subsection{Configuration Change Penalty}
\label{subsec:Concept:ReccomendationGeneration:Penalty}

In this thesis a penalty function is proposed which gives the percentage of characteristics that exist in the configuration that is to be rated. This value can be tuned to be more or less strict by potentiating. This is done by selection different values for $\alpha$. Thereby allowing more deviation or less deviation from the current configuration state. The penalty function is defined as
\begin{equation}
    \notag \alpha \in \mathbb{R}, \qquad     unchanged(d,\overline{s}, s) = 
    \begin{cases}
      1, & d \in \overline{s} \land d \in s \\
      0, & \text{otherwise}
    \end{cases}
\end{equation}

\begin{equation}
    penalty_{proportion}(\overline{s},\ s) =  \left(\frac{\sum_{d \in \overline{s}} unchanged(d,\overline{s}, s)}{|\overline{s}|}\right)^\alpha.
\end{equation}
In essence the the function checks the number of unchanged characteristics and divides this by the number of characteristics that are in the current configuration state. The result is the proportion of unchanged characteristics when comparing the current configuration state to the finished configuration.

By including the current configuration state, the scoring function can take into account that some characteristics have already been realized and therefore might be very costly to change. A higher $\alpha$ resembles a higher cost of change and an alpha of zero represents no costs for changes.

\section{Illustration}
\label{sec:Concept:Illustration}

This section gives an example to illustrate how the recommendation works. The example in \autoref{fig:Concept:ForestExample} is used for that but the preferences are extended. \autoref{tab:Concept:UseCaseConfigurations} shows the current configuration state which consists of the characteristic moderate for the feature \textit{indigenous} and  \textit{resilient} respectively. $S_{F1}$ to $S_{F4}$ show the stored configurations for this example. The features that will be focused on are \textit{indigenous}, \textit{resilient} and \textit{effort}. In the presented example $S_{F1}$ performs best. The exact reason for that will be presented here. $S_{F1}$ is compared to $S_{F2}$ to show the effect of divergence from the configuration state.  A comparison between $S_{F1}$  and $S_{F3}$ is done to show the difference between preferences and the effect on the score and last, $S_{F4}$ is done to show the effect of switching to better preferences but diverging from the current state. The configurations all differ to $S_{F1}$ in only one characteristic that is chosen differently. As aggregation strategy the \emph{average} metric is used (see \autoref{sec:Foundations:GroupRecommenderSystem}). The parameter $\alpha$ (see \autoref{subsec:Concept:ReccomendationGeneration:Penalty}) is set to 1. A lower $\alpha$ reduces the penalty given to configurations that deviate from the configuration state $S$ and a higher $\alpha$ increase the reluctance to change.

The difference between  $S_{F1}$ and  $S_{F2}$ is that instead of containing \emph{moderate} for the feature \emph{resilient} $S_{F2}$ contains \emph{high}. The scores for these two characteristics are the same, with a value of $0.55$, as both users have rated them at $0.5$ but since $S_{F2}$ deviates from the configuration state there will be a penalty. There are two characteristics in the configuration state $S$, therefore, the penalty is $(\frac{1}{2})^\alpha = (\frac{1}{2})^1 = 0.5$. This means the score of $S_{F2}$ is half of $S_{F1}$, resulting in a final score of $0.275$ compared to $0.55$.

The only difference between $S_{F1}$ and $S_{F3}$ is that $S_{F3}$ changes the selection for the feature \emph{effort}. The characteristic \emph{manual} is chosen in $S_{F1}$ and the characteristic \emph{harvester} for $S_{F3}$. The individual score for user one increases as he prefers \emph{harvester} with $0.8$ over \emph{manual} with $0.6$. However, user two has an individual score reduction as her score changes from $0.8$ for \emph{manual} to $0.3$ for \emph{harvester}. The larger decrease in the score of user two causes a decrease in the overall score when comparing  $S_{F1}$ to $S_{F3}$ with a score of $0.55$ to $0.53$. The scores for both users are closer together for $S_{F1}$. However, this does not necessarily have to be the case if the preference of user two for harvester were to change to $0.6$ because then both configurations would have the same score. A different user preference aggregation strategy can change that.

Last, $S_{F1}$ and $S_{F4}$ differentiate in terms of the characteristic choice for the feature \emph{indigenous}. The switch from \emph{moderate} to \emph{high} when changing from $S_{F1}$ to $S_{F4}$ causes an increase in the individual scoring function of user two. This is caused because her preference for \emph{moderate} is $0.6$ and for \emph{high} is $0.9$. This results in a score of $0.57$ for $S_{F4}$. Yet, the change that causes the preference scoring function to give a higher score entails a penalty as the characteristic \emph{high} is not part of the configuration state. This penalty causes the overall score to drop to $0.29$ compared to the score of $S_{F1}$ with $0.55$.

\begin{table}
    \tiny
    \begin{tabularx}{\columnwidth}{C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|}
        & \multicolumn{3}{c|}{\textit{indigenous}} & \multicolumn{3}{c|}{\textit{resilient}} & \multicolumn{3}{c|}{\textit{usable}} & \multicolumn{3}{c|}{\textit{effort}} & \multicolumn{3}{c|}{\textit{quantity}} & \multicolumn{3}{c|}{\textit{price}} & \multicolumn{3}{c|}{\textit{accessibility}} \\
        \rotatebox[origin=c]{90}{\ preferences} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{manual} & \rotatebox[origin=c]{90}{harvester} & \rotatebox[origin=c]{90}{autonomous} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} \\
        \hline
        $P_1$   & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & \textbf{0.1} & \textbf{0.7} & \textbf{0.9} & \textbf{0.6} & \textbf{0.8} & \textbf{0.2} & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 \\
        $P_2$   & \textbf{0.1} & \textbf{0.6} & \textbf{0.9} & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & \textbf{0.8} & \textbf{0.3} & \textbf{0.1} & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 \\
    \end{tabularx}
    \caption{A table showing the preferences of an example for this section.}
    \label{tab:Concept:UseCaseRating}
\end{table}

\begin{table}
    \tiny
    \begin{tabularx}{\columnwidth}{C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|}
        & \multicolumn{3}{c|}{\textit{indigenous}} & \multicolumn{3}{c|}{\textit{resilient}} & \multicolumn{3}{c|}{\textit{usable}} & \multicolumn{3}{c|}{\textit{effort}} & \multicolumn{3}{c|}{\textit{quantity}} & \multicolumn{3}{c|}{\textit{price}} & \multicolumn{3}{c|}{\textit{accessibility}} \\
        \rotatebox[origin=c]{90}{\ configuration} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{manual} & \rotatebox[origin=c]{90}{harvester} & \rotatebox[origin=c]{90}{autonomous} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} \\
        \hline
        $S_{\ \ }$         & - & \pmb{\checkmark} & - & - & \pmb{\checkmark} & - & - & - & - & - & - & - & - & - & - & - & - & - & - & - & - \\
        $S_{F1}$    & - & \pmb{\checkmark} & - & - & \pmb{\checkmark} & - & - & \checkmark & - & \pmb{\checkmark} & - & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
        $S_{F2}$    & - & \pmb{\checkmark} & - & - & - & \pmb{\checkmark} & - & \checkmark & - & \pmb{\checkmark} & - & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
        $S_{F3}$    & - & \pmb{\checkmark} & - & - & \pmb{\checkmark} & - & - & \checkmark & - & - & \pmb{\checkmark} & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
        $S_{F4}$    & - & - & \pmb{\checkmark} & - & \pmb{\checkmark} & - & - & \checkmark & - & \pmb{\checkmark} & - & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
    \end{tabularx}
    \caption{The current configuration state $ S $ and the stored finished configurations $ S_{Fi} $.}
    \label{tab:Concept:UseCaseConfigurations}
\end{table}
 