\chapter{Controller Design and Evaluation}
In this chapter a control system is designed and evaluated to stabilize \glspl{flute} \gls{rf} system.
Referring back to the block diagram of a generic control system in \autoref{fig:theoreticalFramework-feedback-architecture}, there are three building blocks of a control system to be determined.
First the plant transfer function, which describes the system that is to be controlled.
Second, based on the plant, an appropriate controller type is chosen and its parameters are calculated.
Third, a measurement filter is used to improve the quality of the feedback signal path. As the choice of the measurement filter influences the controller design, its design is treated before the controller.

\section{Plant Identification}\label{sec:plantIdenti}
\subsection{Principle}
Before choosing an appropriate controller, some insight of the system response has to be obtained. Therefore in this section the plant's transfer function is estimated. In the context of this chapter ``plant'' refers to everything from the attenuation set at the controllable attenuator to the system output, e.g. the cavity \gls{rf} power.

In the time domain, a \gls{lti} system is described by its impulse response $h(t)$, that is the reaction of the plant to an impulse at the input.
Using this definition directly, the plant's impulse response $p(t)$ could be measured by applying a short peak in the attenuation setting on the attenuator. The effect on the output is not easy to measure and a single measurement of this kind is very susceptible to noise.
Therefore it is more common to measure the step response, which is the output of a system, when a step function is applied to its input. As the step function is the time integral of the impulse function, the step response can be converted to the impulse response by differentiation in time. \cite{Wang2000}

Instead of measuring a single step response, often several step responses are measured and their average is computed to reduce the variance of the estimation. When measuring a step response the minimum needed measuring time depends on the systems time constants, but they are often not known beforehand.

That is why when there is no prior knowledge of the system, the identification is sometimes done with a \gls{prbs} to excite the system with step functions of different lengths. The \gls{prbs} is chosen in a way that some of the steps will probably last longer than a few dominant time constants of the system.

To get the transfer function $P(s)=\mathcal{L}\left\{p(t)\right\}$ of the plant from its step response(s), several methods are common, including correlation based and frequency response based algorithms.

\subsection{Identifying the Plant Attenuator \& RF system}
The input \gls{prbs} signal is generated with the Python script in \autoref{lst:controllerDesignAndEvaluation-randomSequence}.
Based on the value of a pseudo random number generator, the sequence toggles the attenuator between $V_\text{control}=\SI{7}{\volt}$ and $V_\text{control}=\SI{11}{\volt}$.
Using \autoref{fig:interfacingFlute_attenDatten}, this equals a span in attenuation of \SIrange{6.892}{6.4026}{\dB}.
With the parameter \texttt{toggleP}, the average length of one constant voltage level can be controlled.

\begin{lstlisting}[style=python,caption = Function to get a pseudo random binary sequence, label = lst:controllerDesignAndEvaluation-randomSequence]
def randomBinarySequence(N,toggleP):
    u=[False]*N
    for i in range(1,len(u)):
        if(np.random.binomial(1,toggleP,1)[0]):
            u[i]=not u[i-1]
        else:
            u[i]=u[i-1]
    return list(map(lambda x: 7 if x==False else 11,u))
\end{lstlisting}

In a test run over six hours (after all \gls{flute} subsystems had stabilized), the attenuator was driven with such a \gls{prbs}. The result is shown in \autoref{fig:controllerDesignAndEvaluation-identify-excitation}.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/ControllerDesignAndEvaluation/img/identification/excitation.tikz}
	\caption[Identification sequence and response]{Section of the input sequence (blue, Attenuation) and the system response (orange, cavity RF power); Note the inverse relation: A higher attenuation $A$ causes a lower cavity power $P_\text{cavity}$}
	\label{fig:controllerDesignAndEvaluation-identify-excitation}
\end{figure}

The time signals $A(t)$ and $P_\text{cavity}(t)$ are then split into an \textit{estimation} data set (about \SI{80}{\percent} of the samples) and a \textit{validation} data set (the remaining $\approx$ \SI{20}{\percent}). This is done so the bulk of the available information is used to estimate the model, but there is data left that the model hasn't seen before. This smaller portion is used to validate the model's performance, hence it is called the validation data set.

The two data sets are then loaded into the \textsc{Matlab} \textit{System Identification Toolbox}. With the toolboxes pre-processing tools, first the means of both the input and output are removed, which is required by the estimators used.
Then, using the ``process model'' estimator, linear, continuous time transfer functions with different numbers of zeros and poles are estimated (See screenshot of the \gls{gui} in \autoref{fig:Appendix-identify}). After that, to check the accuracy of the estimations, the System Identification Toolbox is used to simulate the output of the estimated systems (see \autoref{fig:controllerDesignAndEvaluation-identify-mo}). For that the aforementioned validation data set is used. The measured output is compared with the outputs predicted by the models.

Using the Matlab function \texttt{zpk()} the models are converted into the zero-pole-gain representation. In
\autoref{tab:controllerDesignAndEvaluation-identify-models} the estimated models are listed with their zeros, poles, gains and the model fit, as it is computed by the System Identification Toolbox. \texttt{P1}, \texttt{P2} and \texttt{P3} are models with one, two and three poles and a gain as free parameters. \texttt{P2ZU} consists of a complex pole pair, a zero and a gain.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/ControllerDesignAndEvaluation/img/identification/modelOutputs.tikz}
	\caption[Validation of the process model]{Validation of the estimated process models for the plant; the legend also shows the model fits in percent}
	\label{fig:controllerDesignAndEvaluation-identify-mo}
\end{figure}

\begin{table}[tb]
\caption[Estimated process models]{Process models of the plant as estimated by the Matlab System Identification Toolboxes process model estimator}
\label{tab:controllerDesignAndEvaluation-identify-models}
\centering
\begin{tabular}{lcccc}
\toprule
Model & Zeros & Poles & Gain & Model fit \\
\midrule
P1   & & $(s+0.3505)$ & $-646.94$ & \SI{89.98}{\percent}\\
P2   & & $(s+0.6875) (s+0.7039)$ & $-873.18$ & \SI{93.83}{\percent}\\
P3   & & $(s+\num{1e06}) (s+0.7376) (s+0.669)$ & $\num{-8.9019e+08}$ & \SI{93.85}{\percent}\\
P2ZU &$(s-2846)$ & $(s^2 + 0.8014s + 0.3195)$ & $0.20296$ & \SI{96.26}{\percent}\\
\bottomrule
\end{tabular}
\end{table}

\autoref{fig:controllerDesignAndEvaluation-identify-mo} and \autoref{tab:controllerDesignAndEvaluation-identify-models} show the \texttt{P2ZU} model to have the best fit. Therefore it is accepted as the plants transfer function. Using the Matlab function \texttt{tf()}, its time continuous transfer function can be stated as
\begin{equation}
P(s) = \frac{0.6352s - 1808}{3.13 s^2 + 2.508 s + 1}.
\end{equation}
Using the Matlab function \texttt{c2d()}\footnote{Without specifying a different method, \texttt{c2d()}  discretizes the continuous-time model zero-order hold on the input.} and the sample time $T_s=\SI{0.2}{\second}$, $G(s)$ can be converted to the time discrete transfer function
\begin{equation}
P[z] = \frac{-10.91 z^{-1} - 10.41 z^{-2}}{1 - 1.84 z^{-1} + 0.8519 z^{-2}}.
\end{equation}

The high model fit percentage of \SI{96.26}{\percent} justifies the choice of a linear model with few parameters and further estimation attempts using other (non-) linear models are not needed.
Considering the accuracy of the model, it is important to note this estimation is only valid at the time the measurements are taken. With \gls{flute} being a large experimental setup being still under commission, it is always possible that small changes to certain (sub-) systems can lead to minor or major influences to others.
For the time being, the estimation is redone a day later and for both measurements days, different parts of the about six hour measurements each are used as the estimation and validation data sets. Doing so shows no significant change in the estimated coefficients and the resulting model fits, indicating the estimated models are at least plausible.

To account for errors in the estimated model (and possible other errors), when designing the controller, sufficient gain and phase margins are set to ensure stable operation.

\newpage
\section{Measurement Filter}\label{sec:measurementFilter}
Like all measurements of physical quantities, the measuring of the system output of the control system is subjected to noise.
In addition to these disturbances of thermal or electrical origins, also high frequency variations of the system output have detrimental effects on the control systems performance.
For example the magnitudes of the bunch-by-bunch changes of the measured cavity power are often in the same order as the long-term drifts.
Trying to correct for them, instead of the long term drifts, often leads to overcompensating and can even make the system unstable.

To remove the high frequency components, a low pass filter is used as the measurement block $H(s)$.

In pre-tests the incoming signal was simply filtered with a moving average filter.
Commonly, the moving average is defined as the mean of a signal $x$ inside a window of length $L$, centered around the current time or sample index $n$, that is shifted along the signal. This smooths out small variations thus the moving average acts as a low pass filter.
This \textit{non-causal} version of the moving average can only be used with already measured data as to compute the moving average at $n$, future values at $n+i$ are needed:
\begin{equation}
\operatorname{MA}_{x,\text{non-causal},L}[n] = \frac{1}{L} \sum_{i=n-\frac{L-1}{2}}^{n+\frac{L-1}{2}} x[i]
\end{equation}
When filtering real-time data, future values are not available and a shifted, \textit{causal} version, of the moving average
\begin{equation}\label{eq:causalMA}
\operatorname{MA}_{x,\text{causal},L}[n] = \frac{1}{L} \sum_{i=n-(L-1)}^{n} x[i]
\end{equation}
is used.

In case of the cavity \gls{rf} power, experiments show a window length of about $L=100$ or more is necessary to sufficiently smooth the measured power signal.
When comparing the original signal with the filtered one, it is apparent that in addition to the desired smoothing effect, the filtered signal also is delayed in time, with the delay being dependent on the window size.
To quantify the delay, the alternative definition of the moving average as a digital \gls{fir} filter is used.
One possibility to describe a \gls{fir} filter is by giving its impulse response, i.e. the output signal when the input of the filter is an impulse with unity height. In case of the moving average filter, the coefficient sequence of the corresponding \gls{fir} filter has the length $N=L$ and is equal to the the impulse response $h[n]$:
\begin{equation}
h[n] = \frac{1}{N} [\underbrace{1,\,1,\,...,\,1}_N]
\end{equation}

The delay introduced by a digital filter can be quantified with the filter's group delay
\begin{equation}
\frac{\tau_g(f)}{T_s} = \frac{\d{\phi(f)}}{\d{f}}
\end{equation}
which is given normalized to the sampling time $T_s$. \cite[p.~70]{Kammeyer2002} In case of a \gls{fir} filter with linear phase (with a symmetrical impulse response), the group delay is always constant over all frequencies and is only dependent on the filter length $N$ (see \cite[p.~165]{Kammeyer2002}):
\begin{equation}\label{eq:groupD}
\frac{\tau_g(f)}{T_s} = \frac{\d{\phi(f)}}{\d{f}} = \frac{\d{\phi}}{\d{f}} = \frac{N}{2}
\end{equation}

With a sampling time of $T_s=\nicefrac{1}{\SI{5}{\hertz}}=\SI{200}{\milli\second}$ and $N=100$ the group delay is \SI{10}{\second}. In case of a steady operation this is acceptable, as the disturbances to compensate happen on a timescale in the order of several minutes.
But in case of ongoing transients due to user changes to the control system parameters or short error bursts on the measured signal, this long delay causes problems and therefore should be reduced.

Therefore a more sophisticated digital filter is designed to replace the simple moving average.

On the one hand, a \gls{fir} filter is designed with the Kaiser window method.
This method starts with the desired frequency response, which is usually given piece-wise.
In case of the low pass filter it is a step function at a cutoff frequency $f_c$.
Then the IDFT is used to compute the corresponding impulse response $h_\text{IIR}[n]$, which is in general infinitely long.
Windowing with e.g. a Kaiser window and then truncating the impulse response yields the impulse response of the desired \gls{fir} filter $h_\text{FIR}[n]$. \cite[p.~533]{Oppenheim2010}
With SciPy using \texttt{b=signal.firwin(N, fc,fs)}, the coefficients of a \gls{fir} with this method can be calculated.

On the other hand, an \gls{iir} filter is designed with the impulse invariance method and an analog Butterworth filter.
This method could be interpreted as sampling the infinitely long analog impulse response. \cite[p.~497]{Oppenheim2010}
In SciPy using \texttt{b,a=signal.butter(N,fc,'lowpass',fs,)}, the coefficients of an \gls{iir} can be calculated with this method.
For an \gls{iir} filter, the group delay cannot be calculated with \autoref{eq:groupD} and it is in general frequency-dependent.

\autoref{fig:controllerDesignAndEvaluation-impulseresponses} shows the impulse responses of the moving average, the \gls{fir} lowpass and the \gls{iir} lowpass (truncated to $N=100$).

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/ControllerDesignAndEvaluation/img/measurementFilter/firVsMa_impulseresponses.tikz}
	\caption[Impulse Responses of different time discrete filters]{Impulse responses of a moving average filter ($N=100$), a \gls{fir} lowpass ($N=50$, $f_c=\SI{0.1}{\hertz}$) and a \gls{iir} Butterworth lowpass ($N=50$, $f_c=\SI{0.1}{\hertz}$)}
	\label{fig:controllerDesignAndEvaluation-impulseresponses}
\end{figure}

In \autoref{fig:controllerDesignAndEvaluation-filterResults}, the three filter types described above are compared by filtering a ten minute long segment of pre-recorded data. The filtering is done with the SciPy function \texttt{signal.lfilter()} which does causal filtering and does not compensate group delay\footnote{In contrast to \texttt{signal.filtfilt()}, which applies the filter both forward and backward achieving zero phase/group delay, but this cannot be done for incoming real-time data.}, so the results are the same as they would be for real-time data.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.65\textwidth]{chap/ControllerDesignAndEvaluation/img/measurementFilter/firVsMa.tikz}
	\caption[Filter effects of different time discrete filters]{Effects of the three different lowpass filters in \autoref{fig:controllerDesignAndEvaluation-impulseresponses} on noisy data}
	\label{fig:controllerDesignAndEvaluation-filterResults}
\end{figure}

The plot shows the \gls{fir} lowpass filter requiring ten times the number of coefficients to achieve about the same result as the \gls{iir} lowpass filter.
Also the moving average filter has double the number of coefficients as the \gls{fir} lowpass filter, but there is still high frequency noise in the output (caused by the $\text{sinc}(\cdot)$ shape of its frequency response $H[f]=\operatorname{DFT}\{h[n]\}$).

Compared to the \gls{fir} lowpass, the moving average offers no benefit besides its easy implementation.
When comparing the \gls{fir} with the \gls{iir} approach, the \gls{iir} has the advantage of needing less coefficients, thus occupying less memory, which is not really an advantage when the control system is implemented on a personal computer, which typically has enough free memory to hold millions of floating point numbers.
Also the \gls{iir} filter has a non-constant group delay and is not guaranteed to be stable like all \gls{fir} filters are.

For these reasons, in the following a \gls{fir} lowpass filter is used.

One example filter generated with \texttt{signal.firwin()} with a cutoff frequency $f_c=\SI{10}{\milli\hertz}$ and order $N=10$ has the transfer function
\begin{equation}
H[z]=\frac{1}{b_{10} z^{10} + b_{9} z^9 + b_{8} z^8 + b_{7} z^7 + b_{6} z^6 + b_{5} z^5 + b_{4} z^4 + b_{3} z^3  + b_{2} z^2 + b_{1} z + b_{0}}
\end{equation}
with the coefficient vector $\vec{b}=[b_{10},\,...,\,b_0]$, with
\begin{equation}
\vec{b}=[0.0876,0.0896,0.0911,0.0922,0.0929,0.0931,0.0929,0.0922,0.0911,0.0896,0.0876].
\end{equation}

Instead of stating the transfer function, a plot of the poles and zeros is a more intuitive representation. In \autoref{fig:controllerDesignAndEvaluation-zplane}, the poles and zeros of the \gls{fir} filter with $N=10$ are compared to one with $N=40$. In addition, \autoref{fig:controllerDesignAndEvaluation-magn} shows the magnitude responses of such filters.

For a fixed cutoff frequency and variable order $N$, the trade-off for choosing $N$ is between the group delay introduced by the filter (see \autoref{eq:groupD}) and the width of the transition band or in other words the sharpness of the filter. This can be seen by comparing the cases $N=10$ and $N=40$ for the \gls{fir} filters in \autoref{fig:controllerDesignAndEvaluation-filterResults}: While the smoothing-effect of the longer filter is obviously better, it also causes a higher group delay, which results in the filter result of the $N=40$ filter being shifted in time by $\frac{40}{2}T_s = \SI{4}{\second}$ compared to $\frac{10}{2}T_s = \SI{1}{\second}$ in case of $N=10$. While a high smoothness is desired for the control system to reject high frequency noise, using a filter with a too high order can introduce a group delay high enough to shift the closed-loop from negative to positive feedback, thus making it unstable.

For the controller design in the next section and the later implemented real-time system, the cutoff frequency and the filter order are kept variable to leave room for improvement.

\begin{figure}[tb]
    \centering
        \subfloat[$N=10$]{\input{chap/ControllerDesignAndEvaluation/img/measurementFilter/lpFiltZPplane10.tikz}}
        \qquad
        \subfloat[$N=40$]{\input{chap/ControllerDesignAndEvaluation/img/measurementFilter/lpFiltZPplane40.tikz}}
       \caption[FIR pole zero maps]{Pole-Zero maps for two \gls{fir} filters with a common cutoff frequency $f_c=\SI{10}{\milli\hertz}$ but different filter orders $N$;\\ $\circ$ denotes zeros, $\times$ denotes poles, $(k)$ is a $k$-times pole}
    \label{fig:controllerDesignAndEvaluation-zplane}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.6\textwidth]{chap/ControllerDesignAndEvaluation/img/measurementFilter/lpFiltMagnitude.tikz}
	\caption[FIR magnitude response]{Magnitude response of two \gls{fir} filters with a common cutoff frequency $f_c=\SI{10}{\milli\hertz}$ but different filter orders $N$}
	\label{fig:controllerDesignAndEvaluation-magn}
\end{figure}

\FloatBarrier
\paragraph{Real-time implementation of a FIR Filter in Python}
Similar to \autoref{eq:causalMA}, a \gls{fir} filter designed with the SciPy function \texttt{sigal.firwin()} can be used in a causal manner to filter real-time data.

Applying the filter on pre-recorded data, like in \autoref{fig:controllerDesignAndEvaluation-filterResults} can be done with \texttt{signal.lfilter()}. To use \texttt{signal.lfilter()} on sample-wise incoming real-time data, the ``initial in'' input and ``final out'' output of \texttt{signal.lfilter()} can be used to keep the filters state. This is demonstrated in \autoref{lst:controllerDesignAndEvaluation-zizf} by looping through pre-recorded data point-by-point.

\begin{lstlisting}[style=python,caption = Demonstration of the \texttt{zi} and \texttt{zf} variables when using \texttt{signal.lfilter()}, label = lst:controllerDesignAndEvaluation-zizf]
x=df2["F:RF:LLRF:01:GunCav1:Power:Out Value"].to_numpy()
y=np.array([])
zf=signal.lfilter_zi(b, 1)
for i in range(len(x)):
    y0,zf=signal.lfilter(b, 1, [x[i]],zi=zf)
    y=np.append(y,y0[0])
\end{lstlisting}

\newpage
\section{Controller Design}
Based on the estimated model of the plant $P(s)$ (or $P[z]$) in \autoref{sec:plantIdenti} and the type of measurement filter designed in \autoref{sec:measurementFilter}, in this section an appropriate controller to stabilize the plant is designed and its performance is evaluated.

Tuning the controller and testing its capabilities is performed both \textit{offline} with simulations using the building blocks $P[z]$, $H[z]$ and the yet to be defined $G[z]$ and \textit{online} using a software implementation of the control system with the real hardware, i.e. \gls{flute} and the controllable attenuator.

\subsection{Choosing a Controller Type}
The plant has been identified using a linear model in \autoref{sec:plantIdenti} resulting in the \gls{lti} system $P(s)$ (or $P[z]$). The matching controller does not necessarily have to be a \gls{lti} system, but choosing a \gls{lti} system simplifies design and analysis and is a justifiable choice here, as there are no good reasons against it, yet.

The class of \gls{lti} controllers is dominated by the \gls{pid} controller and its variants. \gls{pid} stands for ``proportional'', ``integral'' and ``derivative'', which are \gls{lti} systems themselves, performing scaling, integration or differentiation. Depending on the application, variants, such as the PI controller, or the PD controller are used as well.

According to \cite[p.~111]{Aastroem1995} \gls{pid} control is applicable for plants with order two or less.
Compared to other types of controllers, using a \gls{pid} controller has many advantages. It is is quick to design and does not depend on an accurate plant model. Also after the designing step, the few free parameters can easily be presented to an operator and online fine tuning is possible.\footnote{In contrast a compensating controller is based on an accurate model of the plant and changes on the fly are difficult. \cite{SergeZacher2010}}

In the next section such a \gls{pid} controller is designed. As it is to be implemented in software later, the design is done in discrete time.

\subsection{Designing a Discrete Time PID Controller}\label{sec:controlDesign}
The output signal $u(t)$ of a generic time continuous \gls{pid} controller (see \autoref{fig:controllerDesignAndEvaluation-genericPID}) consists of the weighted sum of three error signals.

\begin{figure}[tb]
	\centering
	\includegraphics[width=0.8\textwidth]{chap/ControllerDesignAndEvaluation/img/controller/pid.tikz}
	\caption[Block diagram of a PID controller]{Block diagram of a generic \gls{pid} controller}
	\label{fig:controllerDesignAndEvaluation-genericPID}
\end{figure}
The first is simply the controller input error signal $e(t)$ scaled by the gain $k_p$. This is the proportional part of the \gls{pid} controller. The integral part is calculated by computing the running time integral
\begin{equation}\label{eq:ei}
e_i(t)=\int_{0}^{t} e(\tau) \d{\tau}.
\end{equation}
This is then scaled by the constant $k_i$. To get the derivative part, the derivative
\begin{equation}\label{eq:ed}
e_d(t)=\frac{\d{}}{\d{t}} e(t)
\end{equation}
is calculated and weighted with $k_d$.
All three are then summed to get $u(t)$ in the so called parallel form (see \cite[p.~5]{Dodds2015}):
\begin{equation}
u(t)=k_p e(t) + k_i \int_{0}^{t} e(\tau) \d{\tau} + k_d \frac{\d{}}{\d{t}} e(t)
\end{equation}
Often instead of the parallel form, the \gls{pid} controller is stated in \textit{standard form}. Instead of using the gains $k_{p,\,i,\,d}$, the parameters proportional gain $K$, integral time $T_i$ and derivative time $T_d$ are used. \cite[p.~76]{Aastroem1995} With the conversions
\begin{align}
K&=k_i\\
T_i=\frac{k_p}{k_i}&=\frac{K}{k_i}\\
T_d=\frac{k_d}{k_p}&=\frac{k_d}{K}
\end{align}
the \gls{pid} controller in standard form is
\begin{equation}
u(t)=K\left[e(t) + \frac{1}{T_i} \int_{0}^{t} e(\tau) \d{\tau} + T_d \frac{\d{}}{\d{t}} e(t)\right].
\end{equation}
The transfer function $G(s)$ is given by the Laplace of $u(t)$ using the computation rules (see \cite{Leon2015})
\begin{align}
\mathcal{L}\left\{\int_{0}^{t} y(\tau) \d{\tau}\right\} &= \frac{1}{s} Y(s)\\
\mathcal{L}\left\{\frac{\d{}}{\d{t}} y(t)\right\} &= s Y(s)
\end{align}
as
\begin{equation}
G(s)=K\left[1+\frac{1}{s T_i}+s T_d\right].
\end{equation}
To get the discrete transfer function, either the Laplace transform $G(s)=\nicefrac{U(s)}{E(s)}$, is discretized or the $\mathcal{Z}$ transform of $u[n]$ is calculated.
First, to get $u[n]$, the derivative in \autoref{eq:ed} is approximated by
\begin{equation}
e_d[n]=\frac{e[n]-e[n-1]}{T_s}.
\end{equation}
This assumes $e(t)$ is sampled with a sampling rate of $f_s=\nicefrac{1}{T_s}$ to get $e[n]$. In a similar fashion, the integral in \autoref{eq:ei} is approximated by
\begin{equation}
e_i[n]=e_i[n-1] + e[n] T_s.
\end{equation}

Using the shift rule of the $\mathcal{Z}$ transform (see \cite{Leon2015})
\begin{equation}
y[n-k] \laplace z^{-k} Y[z],
\end{equation}
the discrete transfer function of the \gls{pid} controller is
\begin{equation}
G[z]=K\left[1+\frac{T_s}{T_i}\frac{z}{z-1}+\frac{T_d}{T_s}\frac{z-1}{z}\right].
\end{equation}
In the time domain, this becomes
\begin{equation}\label{eq:pidn}
u[n] = k_p e[n]
+ k_i \left(\underbrace{e_i[n-1] + T_s e[n]}_{e_i[n]}\right)
+ k_d \left(\underbrace{\frac{1}{T_s} e[n]-e[n-1]}_{e_d[n]}\right)
\end{equation}

\paragraph{Controller Tuning}
Next the three free parameters $k_{p,\,i,\,d}$ or $K,\,T_{i,\,d}$ are to be chosen in such a way that the controller has optimal performance. This process is called \textit{tuning}. Tuning of the parameters can be performed online or offline.

Online tuning is done by using the physical\footnote{``Physical'' in the sense that one could touch it. (But should one?)} plant. One of the most popular member of this class is the Ziegler-Nichols tuning. The method relies on experiments and tabulated values. The mostly used variant uses one measured step response. \cite{Ziegler1942}

Using this method at \gls{flute} produced mixed results. While being a very simple and fast process, the resulting controller is often unstable. This is partially due to errors when extracting the tabulated values from the noisy step response, but also the method intrinsically leads to poor stability margins. \cite[p.~142]{Aastroem1995}
Nonetheless the Ziegler-Nichols method yields a usable starting point, if the strategy is to fine tune the controller manually by intuition and experience of the user.

As the Ziegler-Nichols method does not yield an acceptable parameter set and the method combined with fine tuning by hand takes a considerable amount of time, next tuning the parameters offline using only the plants transfer function and the measurement filter is done.
The offline tuning can be done analytically or using different numerical optimization strategies. In \cite{DiazRodriguez2019} analytical methods, such as the internal model control design or the pole placement design are discussed. Both require the system's transfer function in a closed form.\\
Tuning by numerical optimization chooses the parameters by a simulation or measured data. Goal of the optimization is to minimize a cost function $J$ like
\begin{equation}
J(\theta) = \sum_{n=0}^{\infty} e_{\theta}[n]^2
\end{equation}
with the parameter vector $\theta=[k_p,\,k_i,\,k_d]$ or $\theta=[K,\,T_i,\,T_d]$:
\begin{equation}
\theta_\text{opt} = \underset{\theta}{\text{argmin}} J(\theta)
\end{equation}

A convenient way to do such an optimization by simulation using the transfer function of the estimated plant is the Matlab \textit{PID Tuner}.

\paragraph{Offline Tuning the Controller with the Matlab PID Tuner}
The Matlab \gls{pid} Tuner accepts different kinds of system models used by the Matlab/Simulink ecosystem. It is possible to directly use estimated models, models defined via their transfer function or the zero-pole-gain representation, Simulink models or combinations of those\footnote{Series connection can be established by multiplying the models transfer functions.}.

The manual of the PID Tuner (see \cite{pidTunerMan}) describes the expected input (see \autoref{fig:controllerDesignAndEvaluation-pidTunersys}). The feedback path has to have unity gain, i.e. there is no measurement filter allowed. Therefore the measurement filter is moved before the junction where the output $y[n]$ would normally be measured. Then the measurement filter $H[z]$ is combined with the plant $P[z]$ to form $Sys[z]$. For that reason $y[n]$ becomes an internal signal of $Sys[z]$. However the new system output $y'[n]=h[z] \ast y[n]$ is not too different from the old one, since $H[z]$ is designed to remove high frequency noise but retain the rest of $y[n]$.

\begin{figure}[tb]
	\centering
	\includegraphics[]{chap/ControllerDesignAndEvaluation/img/controller/pidTunerArch.tikz}
	\caption[System architecture for the Matlab PID tuner]{Required system architecture for the Matlab PID Tuner; PID Tuner input is the system block $Sys[z]$ (green), generated output is the controller $G[z]$ (blue)}
	\label{fig:controllerDesignAndEvaluation-pidTunersys}
\end{figure}

The manufacture's documentation in \cite{pidTuner} does not disclose any internals of the PID Tuner nor state which optimization technique is used, but three tuning objectives are stated:
\begin{itemize}
\item Stability: The closed loop should be stable (that is BIBO stable as defined in Definition~\ref{def:bibo})
\item Performance: The closed loop system tracks the input well and rejects disturbances as rapidly as possible (see \autoref{sec:drandtrack})
\item Robustness: A gain and phase margin accounts for errors in the system model (see \autoref{sec:plantIdenti})
\end{itemize}

Using \autoref{lst:controllerDesignAndEvaluation-pidTuner}, the estimated plant $P[z]$ is loaded, a measurement filter $H[z]$ is generated and the combination $Sys[z]=P[z]H[z]$ is fed into the PID Tuner.

\begin{lstlisting}[style=matlab,caption = Matlab script to generate an input system for PID Tuner, label = lst:controllerDesignAndEvaluation-pidTuner]
% design lowpass measurement filter H
N=10;
lpFilt1 = designfilt('lowpassfir', 'FilterOrder', N, 'CutoffFrequency', ...
                    0.01, 'SampleRate', 0.2, 'DesignMethod', ...
                    'window', 'Window', 'kaiser');

% convert filter to a dynamic system
[z1,p1,k1]=zpk(lpFilt1);
H1=zpk(z1,p1,k1,0.2);

% load estimated transfer function and convert it to discrete form
load('P2ZU.mat')
P=c2d(idtf(P2ZU),0.2);

Sys1=tf1*H1; %Combine plant P and measurement filter H
pidTuner(Sys1); %Launch pidTuner
\end{lstlisting}

Using the PID Tuner \gls{gui} (see \autoref{fig:Appendix-pidTuner}), the controller is designed by changing the design parameters \texttt{Response Time} (RT) and \texttt{Transient Behavior} (TB). Changing the response time (in seconds) influences how fast the controller acts on changes. With the transient behavior setting, the allowed over- and under-shoots, that is, the deviation above and below the final value for $t \rightarrow \infty$ can be set qualitatively.

With this tool four different controllers are designed, two for each measurement filter's order of $N=10$ and $N=40$. The transient behavior with $0.2$ for all controllers is chosen as a compromise between speed and overshoot behavior. The optimized \gls{pid} parameters (for a discrete time \gls{pid} controller in parallel form) are listed in \autoref{tab:controllerDesignAndEvaluation-pidTunerResults}.

\begin{table}[tb]
\caption[Calculated PID parameters]{Parameters of a discrete time \gls{pid} controller in parallel form calculated with the Matlab PID Tuner; $N$ is the order of the used measurement filter}
\label{tab:controllerDesignAndEvaluation-pidTunerResults}
\centering
\begin{tabular}{lSSSSSS}
\toprule
Name & {$N$} & {RT (in \si{\second})} & {TB} & {$k_p$} & {$k_i$} & {$k_d$} \\
\midrule
$G_1[z]$ &10 & 5   & 0.2 & \num{-0.000577} & \num{-0.000197} & \num{-0.000421}\\
$G_2[z]$ &10 & 10  & 0.2 & \num{-0.000155} & \num{-0.000111} & \num{-5.43e-05}\\
$G_3[z]$ &40 & 5   & 0.2 & \num{-0.000559} & \num{-2.27e-05} & \num{-0.000396}\\
$G_4[z]$ &40 & 10  & 0.2 & \num{-0.00035} & \num{-9.68e-05} & \num{-0.000316}\\
\bottomrule
\end{tabular}
\end{table}

\subsection{Analyzing the Input Tracking and Disturbance Rejection}
The PID Tuner defaults to show the input tracking step response (as in \autoref{fig:Appendix-pidTuner}).
The input tracking is calculated based on \autoref{eq:inputTracking}. To calculate it, the Matlab function \texttt{step()} is used, which generates the step response plot of a dynamic system, in this case $F_T$. As the whole system only consists of linear building blocks, using an arbitrary step height of $1$ is possible. The response is then normalized in such a way that the final value is also $1$.

In \autoref{fig:controllerDesignAndEvaluation-pidTunerITN10} and \autoref{fig:controllerDesignAndEvaluation-pidTunerITN40} the input tracking step responses for all four controllers are plotted. Note the different $t$ scales. As expected, for longer measurement filters, i.e. filters of higher orders, the controller has to act less aggressive. This causes longer settling times.
Especially \autoref{fig:controllerDesignAndEvaluation-pidTunerITN40} shows that setting a shorter response time does not automatically cause the controller to set the output faster to its final value. While for the shorter response time, the set value is reached quicker, there is also a strong oscillation, so choosing the longer response time (see $G_4[z]$) can be beneficial.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.6\textwidth]{chap/ControllerDesignAndEvaluation/img/controller/pidTuner/trackingN10.tikz}
	\caption[Input tracking of controller one and two]{Step response of the input tracking $F_T$ for controller $G_1[z]$ and $G_2[z]$, designed with the plant $P[z]$ and a measurement filter of order $N=10$, response time goal set to \SI{5}{\second} and \SI{10}{\second}}
	\label{fig:controllerDesignAndEvaluation-pidTunerITN10}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.6\textwidth]{chap/ControllerDesignAndEvaluation/img/controller/pidTuner/trackingN40.tikz}
	\caption[Input tracking of controller three and four]{Step response of the input tracking $F_T$ for controller $G_3[z]$ and $G_4[z]$, designed with the plant $P[z]$ and a measurement filter of order $N=40$, response time goal set to \SI{5}{\second} and \SI{10}{\second}}
	\label{fig:controllerDesignAndEvaluation-pidTunerITN40}
\end{figure}

As the set-point for \gls{flute} only changes occasionally, basically a fixed set-point controller is needed. Therefore the disturbance rejection is more important than the input tracking when analyzing the controllers performance. The step responses of the disturbance rejection $F_{DR}$ are calculated in a similar way as the input tracking, using \autoref{eq:disturbanceRejection} and \texttt{step()}. The $y$ axes are normalized so that the initial value is $1$ and the final value for $t \rightarrow \infty$ is $0$.

In \autoref{fig:controllerDesignAndEvaluation-pidTunerDRN10} and \autoref{fig:controllerDesignAndEvaluation-pidTunerDRN40} the results for all controllers in \autoref{tab:controllerDesignAndEvaluation-pidTunerResults} are plotted.

This shows that even for an optimistically low measurement filter order of $N=10$, the settling time is in the order of slightly under a minute. This is sufficient for the application, but has more of a practical drawback: when fine-tuning the \gls{pid} parameters manually on the machine, it is necessary to wait a few minutes after setting new parameters before assessing the change.

Especially when looking a the plots of $G_3[z]$, it is obvious that there can be stability issues when using a too aggressive controller. For that reason in the next section the stability of the four controllers is analyzed.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.6\textwidth]{chap/ControllerDesignAndEvaluation/img/controller/pidTuner/rejectionN10.tikz}
	\caption[Disturbance rejection of controller one and two]{Step response of the disturbance rejection $F_{DR}$ for controller $G_1[z]$ and $G_2[z]$, designed with the plant $P[z]$ and a measurement filter of order $N=10$, response time goal set to \SI{5}{\second} and \SI{10}{\second}}
	\label{fig:controllerDesignAndEvaluation-pidTunerDRN10}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.6\textwidth]{chap/ControllerDesignAndEvaluation/img/controller/pidTuner/rejectionN40.tikz}
	\caption[Disturbance rejection of controller three and four]{Step response of the disturbance rejection $F_{DR}$ for controller $G_3[z]$ and $G_4[z]$, designed with the plant $P[z]$ and a measurement filter of order $N=40$, response time goal set to \SI{5}{\second} and \SI{10}{\second}}
	\label{fig:controllerDesignAndEvaluation-pidTunerDRN40}
\end{figure}

\subsection{Analyzing the Controller Stability}
In this section the stability of the controllers $G_{i}[z]$ from the last section is evaluated.

For that the Nyquist criterion according to Definition~\ref{def:Nyquist} is used. With the Matlab function \texttt{nyquist()}, the locus $w=F_o[w=j2\pi f]$ of the open loops
\begin{equation}
F_o[z]=G[z] P[z] H[z]
\end{equation}
are calculated. For all controllers designed, they are plotted in \autoref{fig:controllerDesignAndEvaluation-pidTunerNyq}.

This shows the gain margin for $G_3[z]$ (in combination with the $N=40$ filter), that is the distance to the critical point $w=(-1,0j)$, is already very small. So in addition to its oscillatory behavior and the longer settling time, there is also the risk that the system can become unstable if there are even small system parameter changes.

\begin{figure}[tb]
	\centering
	\includegraphics[]{chap/ControllerDesignAndEvaluation/img/controller/pidTuner/nyquist1.tikz}
	\caption[Nyquist plot for all controllers]{Nyquist plot to analyze the stability of the closed-loop control system based on the locus plot of the open-loop system; Note the critical point $(-1,\,0j)$ is always on ``left'' of the curve indicating stability}
	\label{fig:controllerDesignAndEvaluation-pidTunerNyq}
\end{figure}

In \autoref{fig:controllerDesignAndEvaluation-pidTunerfails} another issue is highlighted. If a controller is designed with a certain measurement filter order $N=N_0$ in mind, but is used together with a filter of order $N=N_1>N_0$, it is very likely the closed loop system becomes unstable. In the figure the controller $G_1[z]$ is used together with the $N=40$ filter. Both the disturbance rejection and the Nyquist plot show the closed loop to be unstable.

\begin{figure}[tb]
    \centering
        \subfloat[Step response of the disturbance rejection; amplitude of oscillations grow over time]{\input{chap/ControllerDesignAndEvaluation/img/controller/pidTuner/rejectionFail.tikz}}
        \qquad
        \subfloat[Nyquist plot; critical point $(-1,\,0j)$ is encircled]{\input{chap/ControllerDesignAndEvaluation/img/controller/pidTuner/nyquistfail.tikz}}
       \caption[Unstable system]{Two signs of an unstable closed loop system, in this case caused by a measurement filter with too high order and/or a too aggressive controller}
    \label{fig:controllerDesignAndEvaluation-pidTunerfails}
\end{figure}

\subsection{Offline Evaluation with Measured Data}
Now the performance of the controller $G_1[z]$ together with the filter order $N=10$ should be evaluated with measured data before testing it with \gls{flute}. This simulation is called offline evaluation.

Offline evaluation of the control system is potentially less accurate due to an incomplete or erroneous model. But on the upside it requires no access to \gls{flute} and no potential downtime of the machine. Also with modern computers the simulation time advances much faster than real-time. Another big advantage is repeatability. With a pre-recorded data-set as the disturbance input, simulations are consistent and do not depend on a changing environment or system parameters.

The offline evaluation is done with Simulink, a block diagram development and simulation environment based on Matlab. The Simulink model (see \autoref{fig:Appendix-simuliunk}) uses the disturbance
\begin{equation}
d[n] = \Delta P_\text{cavity}[n] = P_\text{cavity}[n] - \mu_{P_\text{cavity}}
\end{equation}
with $\mu_{P_\text{cavity}}$ being the time average of $P_\text{cavity}[n]$ over one hour. $P_\text{cavity}[n]$ is re-sampled to $T_s=\SI{0.2}{\second}$.
With this calculation of $d[n]$, it is assumed that the disturbance is the deviation of the cavity power from a (theoretical) set-point of $\mu_{P_\text{cavity}}$.

With the simulation the effect of adding $d[n]$ to a system without any feedback and a system with the controller $G_1[z]$ and the measurement filter is compared. The result is shown in \autoref{fig:controllerDesignAndEvaluation-simulinkResult}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/ControllerDesignAndEvaluation/img/controller/simulink/offlineSimulation.tikz}
	\caption[Output offline evaluation]{Output of the Simulink model in \autoref{fig:Appendix-simuliunk}; step size $T=\SI{0.2}{\second}$, end time $\SI{3600}{\second}$. Simulation time on a computer equipped with an Intel i7-3770: \SI{3.5}{\second}}
	\label{fig:controllerDesignAndEvaluation-simulinkResult}
\end{figure}

\newpage
\section{Implementation of the Control System in Software}
In this section the findings from the beginning of this chapter are used to implement a time discrete control system, that is a time discrete \gls{pid} controller that is used to drive the controllable attenuator based on filtered measurements from the system.

The system should be implemented as software that runs on most personal computers and requires few external dependencies to make it as portable as possible. The other core requirements can be summarized to be:
\begin{itemize}
\item Communicate with \gls{epics} (over an Ethernet connection) to read in data such as $P_\text{cavity}[n]$
\item Provide means to filter the incoming data with a measurement filter $H[z]$ with variable order $N$ and cutoff frequency $f_c$
\item Calculate the control error $e[n]$ and based on that the controller output $u'[n]$. Then convert the controller output, an attenuation, to the matching control voltage $V_\text{control}$
\item Communicate with the Keysight 34972A over \gls{vxi-11} (over an Ethernet Network) to set the control voltage $V_\text{control}[n]$ of the attenuator
\item The control routine of the program needs to be light-weight enough so a scheduler can call it faster than five times a second to achieve a sampling time of \SI{0.2}{\second}
\item Show the input, the output and the error signals to the user on a \gls{gui}
\item Provide graphical input elements to let the user modify the measurement filter and the controller parameters ($k_p$, $k_i$, $k_d$)
\item Log the input, output and parameters to disk for later reference
\end{itemize}

Since many other choices depend on it, first the programming language has to be picked. As Python was used in earlier chapters and the communicating abilities to both \gls{epics} and the Keysight 34972A were already proven, it is the obvious choice.

From there on the \gls{gui} framework is the next decision to be made. For Python popular choices are \textit{Tkinter}, a built in implementation of the Tk/tcl \gls{gui} toolkit, \textit{wxPython}, a Python binding to the cross-platform \gls{gui} library wxWidgets, or \textit{PyQt}(see \cite{pyqt}), a set of Python bindings for the Qt \gls{gui} framework. \cite{qt} While Tkinter has the advantage of being built into the Python language, wxPython offers more functionality and is more widely adopted. PyQt profits from the large Qt ecosystem, so is it for example possible to develop the \gls{gui} separately from the code using \textit{Qt Designer}.

For (live-) plotting of data in the \gls{gui}, the standard library in Python is \textit{matplotlib}. \cite{Hunter2007} It can be used with all three plotting libraries. However the biggest drawback is the possible update speed of the plots. With more than about a hundred points on the screen, the update frequency drops to well below \SI{1}{\hertz}. A much faster alternative is \textit{pyqtgraph} (see \cite{pyqtgraph}), a scientific plotting library written in Python and using the Qt GraphicsView. It is only compatible only with PyQt (or the PySide alternatives).

Therefore PyQt and pyqtgraph are used to build handle the \gls{gui} and plot the live data. Also Qt Designer is used to model the \gls{gui} graphically.

The control algorithm is implemented by directly using the equations derived in \autoref{sec:controlDesign}. The time domain representation of the \gls{pid} controller is (restated from \autoref{eq:pidn})
\begin{equation}\label{eq:pidn2}
u[n] = k_p e[n]
+ k_i \left(\underbrace{e_i[n-1] + T_s e[n]}_{e_i[n]}\right)
+ k_d \left(\underbrace{\frac{1}{T_s} e[n]-e[n-1]}_{e_d[n]}\right)
\end{equation}
When translating \autoref{eq:pidn2} to code, the recursion ($e_i[n]$ depending on $e_i[n-1]$) is solved by introducing a variable that keeps track of $e_i[n]$ over time. The last value of $e[n]$, $e[n-1]$ is kept in memory for the derivative part.
An example in pseudo code is listed in \autoref{lst:controllerDesignAndEvaluation-pidcode}.

\begin{lstlisting}[caption = PID controller implemented in pseudo code, label = lst:controllerDesignAndEvaluation-pidcode]
while(true) {
	e := x_set - x_actual
	e_i := e_i_old + e*T_s
	e_d := (e-e_old)/T_s
	e_i_old := e_i
	e_old := e
	wait_sec(0.2)
}
\end{lstlisting}

To get the timing right and to allow the \gls{gui} to be responsive while the control algorithm runs in the background, a scheduler that activates a callback function every \SI{0.2}{\second} should be used. Since in \autoref{sec:atteneval} the Advanced Python Scheduler (AP scheduler) is used successfully, it should also be used for the control system. Unfortunately the AP scheduler is not compatible with PyQt and using it interferes with the internal Qt timing systems. For this reason, a timer is constructed instead with the  \texttt{QTimer} class. \cite{qtimer}

Logging the data to disk is done by using the same \texttt{QTimer} as is used for the control algorithm, to write one line of \gls{csv} data to disk each time the timer is triggered.

With these building blocks ready, the \gls{gui} is build with Qt Designer and based on the \texttt{.ui} file generated from Qt Designer the \gls{gui} Application is implemented. For a screenshot of the program running see \autoref{fig:Appendix-qt}.

\newpage
\section{Evaluation of the Control System (Online) and Conclusion}
After evaluating the controller offline, it is now time to evaluate the performance of the control system on the machine. To do so, \gls{flute} is operated with and without the control system (using the controller $G_1[z]$ and the FIR filter with order $N=40$) switched on for \SI{6}{\hour} each. Before the test, \gls{flute} is allowed to run a few hours for all components to reach operating temperatures.
The result of the test is shown in \autoref{fig:controllerDesignAndEvaluation_resultTime}.
Note, that in this test about \SI{7}{\hour} into the experiment there was an unexpected shutdown of \gls{flute} and the corresponding block of data is removed before further processing.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.65\textwidth]{chap/ControllerDesignAndEvaluation/img/results/result_timesignal.tikz}
	\caption[Time signal whole experiment]{Cavity power over about \SI{15}{\hour} (about three hours of downtime removed for clarity around the \SI{7}{\hour} mark); control system switched off at \SI{6}{\hour} (recording started 2021/05/01 20:00)}
	\label{fig:controllerDesignAndEvaluation_resultTime}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.65\textwidth]{chap/ControllerDesignAndEvaluation/img/results/result_spectrogram.tikz}
	\caption[Spectogram of \autoref{fig:controllerDesignAndEvaluation_resultTime}]{Spectrogram of the cavity power in \autoref{fig:controllerDesignAndEvaluation_resultTime}}
	\label{fig:controllerDesignAndEvaluation_resultSpectg}
\end{figure}

The time plot \autoref{fig:controllerDesignAndEvaluation_resultTime} and also the spectogram in \autoref{fig:controllerDesignAndEvaluation_resultSpectg} show the cavity \gls{rf} power approximately reaches stationarity in the $[0,\,6]\,\si{hour}$ interval respectively in the $[6,\,12]\, \si{hour}$ interval.
This allows the spectrum for these two blocks to be estimated using a periodogram method. In \autoref{fig:controllerDesignAndEvaluation_resultPeriodo} the spectra for each case are shown. The corresponding time data is plotted in \autoref{fig:controllerDesignAndEvaluation_resultComp}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.7\textwidth]{chap/ControllerDesignAndEvaluation/img/results/controllerOnVsOff.tikz}
	\caption[Controller success time signal]{The cavity RF power plotted over time for the two cases control system on and control system off (recorded one after the other and overlayed for comparison)}
	\label{fig:controllerDesignAndEvaluation_resultComp}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.7\textwidth]{chap/ControllerDesignAndEvaluation/img/results/controllerOnVsOffSpectrumErrorBand.tikz}
	\caption[Controller success spectrum]{Power spectrum of the plots in \autoref{fig:controllerDesignAndEvaluation_resultTime} computed with Welch's method; shaded areas show the uncertainty according to \autoref{eq:varWelch}}
	\label{fig:controllerDesignAndEvaluation_resultPeriodo}
\end{figure}

With the periodogram data, the control system success can be measured with the most prominent noise metric.

Next, the cases controller on and controller off should be compared with the relative standard deviation. Measuring and displaying the relative standard deviation $\op{\%STD}$ is also supported on the \gls{llrf} \gls{css} panel at \gls{flute}, so while the experiments run, the values are checked from time to time. It can be observed that different values are shown over time although the plotted time signal looks stationary by eye. This suggests that the relative standard deviation does not only depend on the window size $T$ over which it is calculated, but also heavily on the absolute position in time $t$. This effect is more visible for small window sizes. The issue is illustrated in \autoref{fig:controllerDesignAndEvaluation_resultSTDp}, where $\op{\%STD}=\op{\%STD}(t,T)$ is plotted as a function of the time $t$ and the window size $T$.

\begin{figure}[tb]
    \centering
        \subfloat[Controller off]{\includegraphics[width=\textwidth,height=0.4\textwidth]{chap/ControllerDesignAndEvaluation/img/stdp_off.tikz}}
        \\
        \subfloat[Controller on]{\includegraphics[width=\textwidth,height=0.4\textwidth]{chap/ControllerDesignAndEvaluation/img/stdp_on.tikz}}
       \caption{Relative standard deviation $\op{\%STD}(t,T)$}
    \label{fig:controllerDesignAndEvaluation_resultSTDp}
\end{figure}

For that reason, for small window sizes, time averages of $\op{\%STD}$ should be used instead of single values. For the measured $\op{\%STD}(t,T)$ for the controller off and the controller on cases, $STD\%(T)$ is plotted in \autoref{fig:controllerDesignAndEvaluation_resultSTDp_means}. This plot shows what is already suggested by \autoref{fig:controllerDesignAndEvaluation_resultSTDp}: with the $\op{\%STD}$ metric, the system seems \textit{less} stable with the controller on, if the $\op{\%STD}$ is calculated over small window sizes e.g. $T=\SI{1}{\minute}$. For very long windows, the dependency on the window position becomes negligible. So for the comparison with the other metrics, $\op{\%STD}(T=\SI{4}{\hour})$ is used.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/ControllerDesignAndEvaluation/img/stdp_means.tikz}
	\caption[Relative standard deviation $\op{\%STD}(T)$]{Relative standard deviation $\op{\%STD}(T)$, shaded areas show $\operatorname{min}\{\op{\%STD}(t,T_0)\}$ and $\operatorname{max}\{\op{\%STD}(t,T_0)\}$, solid lines show $\operatorname{mean}\{\op{\%STD}(t,T_0)\}$ for a fixed window size $T=T_0$}
	\label{fig:controllerDesignAndEvaluation_resultSTDp_means}
\end{figure}

With the metrics from \autoref{sec:metrics}, the success of the control system is assessed in \autoref{tab:controllerDesignAndEvaluation_metrics}.

\textbf{Conclusion:}\\
Regarding $\op{\%STD}=\SI{0.0599}{\percent}$, achieved with the control system, shows the \textbf{success} of the control system. With the controller, the variation of the cavity \gls{rf} power can be brought down to lie inside the \SIrange{0.01}{0.1}{\percent} goal, set in \autoref{eq:goalstd}.\\
Using the $\op{MPN}$ metric shows the dominant noise component, caused by the electron gun temperature change, to be reduced by \SI{12.6}{\percent}.

\begin{table}[tbh]
\centering
\caption{Quantitative assessment of the controllers performance}\label{tab:controllerDesignAndEvaluation_metrics}
\begin{tabular}{lSSS}
	\toprule
	Metric                 & {Controller off} & {Controller on} & {Controller off/Controller on} \\ \midrule
	$\%STD(\SI{4}{\hour})$ & 0.11559          & 0.0599225       & 1.92891                        \\
	$MSE$                  & 37.639           & 0.10133         & 371.44                         \\
	$MPN$                  & 0.0170           & 0.0151          & 1.126                          \\ \bottomrule
\end{tabular}
\end{table}

\section{Further Improvements to the Control System}
In this section, two method for improving the control system's performance are examined. First the closed-feedback loop is supplemented with an additional input for one disturbance source, the gun's body temperature. A different approach tested is switching from the gun cavity \gls{rf} power to the electron charge, as measured by the Faraday cup at the end of the low-energy section, as the controlled signal.

\subsection{Disturbance Feed-Forward of the Gun Temperature}
Instead of changing only the parameter of the \gls{pid} controller or switching to another type of controller, the strategy presented here relies on changing the architecture over the standard form (see \autoref{fig:theoreticalFramework-feedback-architecture}) to include a feed-forward path\footnote{The calculations here are done in continuous time to be comparable with the control system model in \autoref{sec:feedbackcontrol}}.

To use the disturbance $d(t)$ ($|d(t)|<\infty$) explicitly in the control system, it has to be measurable separately from the control system's output $y(t)$. This can be only done practically if either all disturbance sources or the dominant ones can be identified and measured with some physical sensor. If the signal $d(t)$ is obtainable, it can be fed into the signal path near the controller. In literature, two locations for the disturbance signal to be injected into are described. The method used decides, among other things, which (if any) filtering of $d(t)$ has to be done.

One technique is to regard the disturbance to be similar to the error signal $e(t)$, i.e. the controller input. \cite{Brosilow2002} In this case, the pre-processing, in general, has to include a scaling operation, because the units and magnitudes of $e(t)$ and $d(t)$ are different. If $d(t)$ has non-zero mean, it needs to be subtracted to achieve linear behavior. This means, the needed disturbance filter is
\begin{equation}
D_1(s)=k_\text{disturbance,1} D'(s),\qquad \text{with } D'(s)=\mathcal{L}\left\{d(t)-\mu_{d(t)}\right\}.
\end{equation}

The second method is to add the filtered disturbance signal to the controller output. \cite{Foellinger2016,electronics7100223} In general, this also requires the same pre-processing as before,
\begin{equation}
D_2(s)=k_\text{disturbance,2} D'(s),\qquad \text{with } D'(s)=\mathcal{L}\left\{d(t)-\mu_{d(t)}\right\},
\end{equation}
but with a different scaling factor $k_\text{disturbance,2} \neq k_\text{disturbance,1}$. This method has the advantage of being potentially faster, because the controller does not occur in the signal path for the disturbance feed-forward, so its dynamics add no additional delay to $d_2(t)$.

In both cases it is common to add another filter to $D_{1,\,2}$. This is often a lowpass filter $H_d()$ to remove noise. The disturbance filter than becomes
\begin{equation}
D(s) = k_\text{disturbance} \cdot H_d(s).
\end{equation}

The new controller architecture is shown in \autoref{fig:controllerDesignAndEvaluation-distfeedforwardArchitecture}. Drawn there is the plant $P(s)$ being split into $P_1(s)$ and $P_2(s)$. This is neither necessary nor possible under all circumstances, but feeding forward the disturbance that acts earlier on the plant would lessen the delay of $d(t)$\footnote{A disturbance that acts on the middle of the plant is different from the one that acts on the end.}. Besides its main purpose of quickly reacting to a disturbance change, the feed-forward also has the inherent benefit of having no influence on the systems stability. Since $d(t)$ is assumed to be finite, the output has to react to $d(t)$ also with a finite response, as the filtered $d(t)$ is only added to $y(t)$.

\begin{figure}[tb]
	\centering
	\includegraphics[]{chap/ControllerDesignAndEvaluation/img/optimization/newArch.tikz}
	\caption[Feed-forward schematic]{Schematic for a control system that uses disturbance feed-forward of the measurable disturbance $d(t)$ in addition to the feed-back loop; changes to the classical control system architecture in \autoref{fig:theoreticalFramework-feedback-architecture} highlighted in yellow(changed) and green(added) (based on \cite[p.~221]{Foellinger2016})}
	\label{fig:controllerDesignAndEvaluation-distfeedforwardArchitecture}
\end{figure}

The new system architecture is tested with $P_1(s)=P(s)$ and $P_2(s)=1$, as it is not possible to split the plant due it's being a black box model. $d(t)$ is set to the electron gun body temperature $\vartheta_\text{gun}$ and $k_\text{disturbance}$ to a constant scaling factor of 0.01.

\textbf{Conclusion:}\\
When testing the newly improved system, there are two observations to be made. First, the stability over a few hours is not improved compared to the system that uses only feedback. But the stability also stays about the same when the control parameters are changed to achieve a slightly ``less aggressive'' controller. Decreasing $k_p$ by a factor of $2$ and $k_i$ by a factor of $4$ does not change stability (measured with the $\op{MSE}$ over \SI{1}{\hour} each) over the feedback-only case.

\subsection{Feedback on Faraday-Cup Charge Measurements}
In the previous part of this chapter, the control input and the measured output was always the cavity power $P_\text{cavity}=P_\text{cavity}(t)$. This power reading is measured with a \gls{rf} power probe in the first half-cell of the electron gun.

But as the electrons are accelerated not only by the half-cell but also by the second and third full-cells, regarding only $P_\text{cavity}(t)$ as a representative for the electron energy can be misleading. Also, the conversion from \gls{rf} power to electron energy depends on the (time-varying) properties of the cavity, so there is no simple linear relation between them fixed in time.

An approach that tries to circumvent these issues uses the dark current. The dark current is normally unwanted, as it is the electron emission from the gun, that is not stimulated by the laser. Without a laser pulse, the electric field, generated by the \gls{rf} inside the first half-cell, accelerates electrons from the vicinity of the cathode that are not freed by the \gls{uv} laser pulse and the photo effect, but rather spontaneous by thermionic emission.

For this dark current, the relation
\begin{equation}
P_B = \frac{I \Delta W}{q},
\end{equation}
holds. It describes the relationship between the power transferred to the beam $P_B$ by the cavity, the current of the beam $I$ and the energy gain $\Delta W$ (with the electron charge $q$). \cite[p.~43]{Wangler2008}

That means by measuring the beam current $I(t)$ or the charge during one pulse
\begin{equation}
Q_\text{B} = \int_{0}^{T_\text{pulse}} I(t) \d{t} = \int_{0}^{\SI{4.5}{\micro\second}} I(t) \d{t},
\end{equation}
it is possible to calculate at least $\nicefrac{P_B}{\Delta W}$.

This charge reading can then be used for the control system input/output as an alternative to the cavity \gls{rf} power.

To measure the charge $Q_\text{B}$, a Faraday cup is used. Faraday cups are hollow metal cups designed to catch charged particles, such as electrons, in vacuum. \cite{radiabeamFaradayCups}

The Faraday cup does not discriminate between the origin of the electrons in the $[0,\,T_\text{pulse}]$ interval. This is different from the the measurements taken with the \gls{ict} and the charge output of one of the \glspl{bpm}. They are only sensitive to the laser-generated electron beam. \cite{Nasse2019}

The charge is captured as a current over some time. This charge then needs to be transformed into a voltage readable by the \gls{flute} data acquisition system, which takes voltages as an input. This is done with a \gls{csa}.

It is similar to an analog integrator (see \autoref{fig:controllerDesignAndEvaluation-integrator}). In principle it can be constructed using an operational amplifier as depicted in \autoref{fig:controllerDesignAndEvaluation-integrator}. \cite[p.~230]{Horowitz2015}

By using the fundamental rules of the ideal model of an operational amplifier, that is the voltage difference between the $+$ and $-$ inputs vanishes and the input currents flowing in the $+$ and $-$ inputs are zero, the input impedance is
\begin{equation}
Z_\text{in} = \frac{V_\text{in}}{I_\text{in}} = R.
\end{equation}

The transfer function in the Laplace space can be directly stated using Kirchhoff's voltage law\footnote{The sum of all signed voltages around a closed loop is zero.} and the complex impedance of a capacitor $Z_C=\frac{1}{sC}$ (with $s=j\omega$) as
\begin{equation}
\frac{V_\text{out}(s)}{V_\text{in}(s)} = -\frac{R+\frac{1}{sC}}{R}.
\end{equation}
Substituting $I_\text{in}(s)=\frac{V_\text{in}(s)}{Z_\text{in}} = \frac{V_\text{in}(s)}{R}$ yields
\begin{equation}
\frac{V_\text{out}(s)}{I_\text{in}(s)} = -\left(R+\frac{1}{sC}\right).
\end{equation}

The \gls{csa} uses no input resistor, so with $R=0$, the transfer function is
\begin{equation}
\frac{V_\text{out}(s)}{I_\text{in}(s)} = -\frac{1}{sC}.
\end{equation}

With $\mathscr{L}\left\{\int_{0}^{t} x(\tau) \d{\tau}\right\}=\frac{1}{s} X(s)$ (see \cite{Leon2015}), the output in the time domain becomes
\begin{align}
V_\text{out}(t) &= \mathscr{L}^{-1}\left\{-I_\text{in}(s) \frac{1}{sC}\right\}\\
                &= -\frac{1}{C} \frac{1}{s} I_\text{in}(s)\\
                &= -\frac{1}{C} \int_{0}^{t} I_\text{in}(\tau) \d{\tau}.
\end{align}

\begin{figure}[tb]
	\centering
	\includegraphics[]{chap/ControllerDesignAndEvaluation/img/optimization/chargeAmp.tikz}
	\caption[Inverting integrator schematic]{Schematic of an inverting integrator using an integrated operational amplifier}
	\label{fig:controllerDesignAndEvaluation-integrator}
\end{figure}

The \gls{csa} uses an adjustable capacity (to set the range of expected charges) and an analog switch to clear the accumulated charge on the capacitor.

At the end of one pulse, the output voltage of the \gls{csa} becomes
\begin{equation}
V_\text{out}(T_\text{pulse}) = -\frac{1}{C} \underbrace{\int_{0}^{T_\text{pulse}} I_\text{in}(\tau) \d{\tau}}_{Q_B} = -\frac{1}{C} Q_B.
\end{equation}
The \gls{csa} has a peak-hold output that keeps the voltage level until it is triggered again.

At the moment, the Faraday cup is mounted at the end of the low energy section. The capacity in the \gls{csa} is resetted at the start of every pulse and outputs a voltage proportional to the range setting and the measured charge. This voltage is measured with a data acquisition system connected to \gls{epics} and thus available in \gls{css} (compare \autoref{sec:inputs}).

To set the range of the \gls{csa}, its serial interface together with a serial to Ethernet adapter is used (See an example of the command structure in \autoref{lst:Appendix-javaPcb}).

\autoref{fig:controllerDesignAndEvaluation-optimCav} and \autoref{fig:controllerDesignAndEvaluation-optimFaraday} show the cavity power and the (un-calibrated) charge reading of the Faraday cup for three different cases: the control system switched off, the control system on with the cavity power used as control input and the control system with the Faraday cup's readout, the electron charge (via the \gls{csa}) as an input.

\textbf{Conclusion:}\\
When the controller controls the cavity \gls{rf} power, it becomes more stable than in the uncontrolled case, while the electron charge changes over time and vise versa. This shows that there is no simple linear dependency between the electron charge and the cavity \gls{rf} power (which is measured only in the half-cell).\\
With electron energy measurements it could be determined if measuring the electron charge is a better indicator for electron energy stability than the cavity \gls{rf} power. As the Faraday cup measurement is destructive, it could instead be advantageous to use additional power sensors in the cavity cells and use their weighted sum as control input instead of $P_\text{cavity}$.

\begin{figure}[tbh]
	\centering
	\includegraphics[width=\textwidth,height=0.65\textwidth]{chap/ControllerDesignAndEvaluation/img/optimization/cavityPower.tikz}
	\caption[Cavity power]{Cavity power with and without control interaction}
	\label{fig:controllerDesignAndEvaluation-optimCav}
	\vspace{2cm}
	\includegraphics[width=\textwidth,height=0.65\textwidth]{chap/ControllerDesignAndEvaluation/img/optimization/faradayCharge.tikz}
	\caption[Electron charge]{Electron charge with and without control interaction}
	\label{fig:controllerDesignAndEvaluation-optimFaraday}
\end{figure}


\section{NPDA for HCL}
\label{NPDA}
\includegraphics[width=\textwidth]{Appendix/images/NPDA.png}