APPLYING MODEL PREDICTIVE CONTROL TO REGULATE THERMALSTABILITY OF A HARD X-RAY MONOCHROMATOR USING THE
KARABO SCADA FRAMEWORK
M. A. Smith∗ , G. Giovanetti, S. Hauf, I. Karpics, A. Parenti, A. Samadli,
L. Samoylova, A. Silenzi, F. Sohn, P. Zalden, European XFEL, Schenefeld, Germany
Abstract
Model Predictive Control (MPC) is an advanced methodof process control whereby a model is developed for a reallife system and an optimal control solution is then calculated
and applied to control the system. At each time step, theMPC controller uses the system model and system state tominimize a cost function for optimal control. The Karabo
SCADA Framework is a distributed control system developed specifically for European XFEL facility, consisting oftens of thousands of hardware and software devices and overtwo million attributes to track system state.
This contribution describes the application of the Python
MPC Toolbox within the Karabo SCADA Framework tosolve a monochromator temperature control problem. Additionally, the experiences gained in this solution have led
to a generic method to apply MPC to any group of Karabo
SCADA devices.

MONOCHROMATORS AT XFEL
European XFEL [1] operates three beamlines capable ofdelivering hard and soft X-rays. For the hard X-ray beamlines, silicon monochromators are used to select the passband of X-ray energies that continue through to the instrument. The monochromator works by using Bragg’s law,which gives the relationship between the incident angle of Xrays on a crystal lattice and the reflected angle. The positionof the crystals is adjustable via motors, in order to control
the incident angle of the X-rays to the silicon crystal’s latticestructure. Python MPC Toolbox [2] was used to solve amonochromator temperature control problem.
Thermal drift in a monochromator causes a drift of thetransmitted photon energy. Silicon is commonly used forHard X-ray Monochromators due to its good commercial
availability and point of zero thermal expansion around
125 K [3]. To mitigate the impact of temperature jumps
caused by the X-ray pulse trains at European XFEL, themonochromator temperature has to stay just below this temperature. A CAD drawing of the two crystals mounted insidea monochromator is shown in Fig. 1. The orange arrow in thedrawing shows the path of the X-ray beam through the twocrystals of the monochromator in a 2-bounce configuration.
To cool the overall monochromator, the silicon crystals areattached to copper plates which are in turn connected to asingle cryogenic cold head to cool the plates down to around
100 K. Each crystal also has a local heating element for finecontrol of each crystal’s individual temperature, along with∗ michael.smith@xfel.eu

SoftwareControl Frameworks for Accelerator & Experiment Control

Figure 1: CAD drawing of the X-ray monochromator, showing the path of the X-ray beam through the two silicon crystals of the monochromator. Tx and HTx identify the temperature sensors and heater elements respectively [4].
a temperature sensor for feedback. Because each crystal
is connected to a common cold head, heat applied to one
crystal will have a time-delayed effect on the temperature of
the other crystal via conduction.
In addition to this, the first crystal in the X-ray path isheated by the X-ray beam. This causes changes in the photon
energy after the first Bragg reflection, which in turn causesa change in angle for the Bragg reflection from the secondcrystal. Tight thermal regulation is very import for ensuringstability of photon energies and the X-ray beam position.

Modeling the Balance of Energies
The transfer of heat from one crystal to the cryo head canbe modeled according to the thermal conduction Eq. (1),where U is the overall heat transfer coefficient of the cryohead, A is the cross sectional area, and 𝑇crystal - 𝑇cryo is thetemperature difference between the crystal and the cryo head.
𝑄 cryo= −𝑈 ∗ 𝐴 ∗ (𝑇crystal − 𝑇cryo )(1)𝑑𝑡
Additionally, the X-ray beam itself imparts heat energy
onto crystals it encounters and needs to be taken into accountwhen setting the heater outputs. This power reading is readily available in the control system from an X-ray gas monitor.
𝑃cryo =TUPDP033
579

Content from this work may be used under the terms of the CC BY 4.0 licence (© 2023). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

19th Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS2023, Cape Town, South Africa
JACoW Publishing
ISBN: 978-3-95450-238-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS2023-TUPDP033

Content from this work may be used under the terms of the CC BY 4.0 licence (© 2023). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

19th Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS2023, Cape Town, South Africa
JACoW Publishing
ISBN: 978-3-95450-238-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS2023-TUPDP033
Only a small fraction of this energy is transferred to the crystal, and can be modeled with an experimentally-determined
reduction factor k.
𝑄 beam= 𝑘 ∗ 𝑃XGM(2)𝑑𝑡
In order to regulate the crystal temperature, an external
controllable heat source adds heat to offset the losses to thecryo head and addition from the X-ray beam. The systembehaviour of one crystal can be described by an equation thatbalances the energy transfers of the system. Using Eq. (3),where m is mass and c is specific heat capacity, we can relateenergy transfers to one crystal with its temperature change.
𝑃beam =𝑃crystal =𝑑𝑄 crystal
𝑑𝑇crystal
= 𝑚𝑐
𝑑𝑡
𝑑𝑡

(3)

𝑑𝑇crystal1=∗ (𝑃cryo + 𝑃heater + 𝑃beam )
(4)
𝑑𝑡
𝑚𝑐
Equation (4) is an ordinary differential equation (ODE)
that describes the rate of change of the system state (processvariables) of one crystal with respect to its system inputs(energy inputs and outputs). An equation like this can becreated for each crystal to describe the rates of change ofcrystal temperatures in terms of other measurable inputs
from the system. With an ODE for each crystal temperature,
the Python MPC toolbox can generate a software model andan optimal controller for this system that can be integrated
into a XFEL’s distributed control system.

SOFTWARE REALIZATION OF AN
OPTIMAL MPC CONTROLLER
The Karabo SCADA Framework
The Karabo SCADA Framework is a distributed control
system developed specifically for European XFEL facility,
consisting of tens of thousands of hardware items and pluggable software components, called devices, that monitor overtwo million attributes. These devices provide a commonsoftware interface to control hardware, read data from sensors, or to create higher-level procedures and functionality
by interfacing to other Karabo devices in a hierarchy. The
Karabo SCADA Framework provides an Application Programming Interface (API) in Python called the Middlelayer
API.

The Python MPC Toolbox
The Python MPC Toolbox is a comprehensive python
library that supports creation, simulation, and runtime implementation of MPCs. This toolbox provides a frameworkin Python for describing a system’s behaviour by defining
the ordinary differential equations (ODEs) that relate the rateof change of its process variables to other measurable statesof the system. Once these are defined, a ‘model’ instance iscreated and can be used by other parts of the MPC Toolbox
to synthesize an optimal MPC controller as well as a modelsimulator.

TUPDP033
580

The MPC toolbox’s Python API lends itself well for use
with the Karabo Middlelayer API. Using the MPC toolbox,
one can program the implementation of all the device’s behavioural logic into the definitions of the MPC’s model. TheMPC Toolbox is capable of incorporating arbitrary or nonlinear constraints into the model as well. Outside the MPC
model definition, the software instructions that remain areneeded only to marshall model inputs and outputs to andfrom the SCADA network.

Integration of the MPC Toolbox
Fixed model parameters are inputs to the model that are
not sourced from a remote device in the control network.
These are defined in the Karabo device just like other numeric parameters of the device. Karabo has a declarative API
which enables the creation of a generic, reusable datatypethat can update the MPC model parameters seamlessly.
""" example d e c l a r a t i o n of Karabo p a r a m e t e r"""
c o n n e c t i o n T i m e o u t = Float (displayedName = " Connection Timeout " ,description = " Maximum time to wait for remote"" device connections . " ,unitSymbol = Unit . SECONDS ,maxInc =10.0)""" example d e c l a r a t i o n of Karabo p a r a m e t e rthat auto - updates MPC p a r a m e t e r"""t e m p e r a t u r e 1 S e t p o i n t = MPCFloat (displayedName = " XTAL1 Temperature Setpoint " ,description = " Temperature setpoint for the "" first crystal in the X - ray path " ,unitSymbol = Unit . DEGREE_CELSIUS ,minInc = -200.0 ,# the d a t a t y p e ’s ’ alias ’ is used to declare# the name of the MPC model v a r i a b l ealias = ’ T_setpoint1 ’)Using these derived classes, MPC model parameters are
exposed in the Karabo device, can be configured at any time,
and the MPC model gets automatically updated. This is usedto implement configurable process control setpoints, fixedmodel constants, and even maximum/minimum boundaries
on MPC variables.
Non-linear and other arbitrary constraints can be imposedon the model through the MPC toolbox API as well. AKarabo property can be defined and its value used to set
lower and upper terminal bounds on any MPC variable inthe model. The MPC toolbox will respect the limits when it
calculates the next control step. Enable and disable toggles
can also be incorporated into the MPC model this way bycreating a Karabo boolean parameter and multiplying theparameter’s numeric value of 0 or 1 against a MPC variablein the model.
With these considerations integrated into the Karabo device parameters, the main process control loop in the Karabo
device becomes very straight-forward. Model inputs are collected from remote Karabo devices, the next step of theSoftware
Control Frameworks for Accelerator & Experiment Control

controller is calculated, then model outputs are written to
remote Karabo devices.
while True :self . elapsed_time = time . time ()# read system state from device proxies# ( get f e e d ba c k v a r i a b l e s from system )y = [ proxy . value for proxyin self . t e m p e r a t u r e P r o x i e s ]# c a l c u l a t e next set of control actionsu = self . mpc . make_step ( y )# apply control actions ( write# new values to device proxies )self . heaterProxies [0]. targetPower = u [0]self . heaterProxies [1]. targetPower = u [1]# time between control actions is defined# in the MPC as self . mpc . t_step
time_step = self . mpc . t_step - \( time . time () - self . elapsed_time )await sleep ( time_step )Simulation and Unit TestingWith a synthesized model, the MPC toolbox can also
create a model simulator for the process under control. This
is of course very useful for confirming the model equations
are defined correctly, and for testing the effect of various
inputs on the model. In this case where we have integrated
MPC into a Karabo device, we also integrate the model
simulator into our Karabo device unit tests.
The Karabo SCADA Framework provides a unit testing
API that allows the creation of mock devices for unit testing.
Creating mock devices with temperature inputs and heater
outputs is a straight-forward effort. With a model simulator,
synthesized from the MPC model, the logic loop in the mockdevices also becomes straight-forward to implement.
self . h1 = M o c k H e a t e r C o n t r o l ({ " _deviceId_ " : " MOCK_H1 " ," targetPower " : 0.0})
self . t1 = M oc k An al og I np ut ({ " _deviceId_ " : " MOCK_T1 " ," value " : -177.70028})
print ( ’ Simulating control response ... ’)while True :# wait for MPC under test to# write new heater output values
await waitUntilNew ( self . h1 . targetPower ,self . h2 . targetPower )# use those outputs to s i m u l a t e the# next i n c r e m e n t in system b e h a v i o u r
u0 = [ self . h1 . targetPower . value ,self . h2 . targetPower . value ]y_next = self . simulator . make_step ( u0 )# set t e m p e r a t u r e sensors to# s i m u l a t e d values
self . t1 . value = y_next [0]self . t2 . value = y_next [1]SoftwareControl Frameworks for Accelerator & Experiment Control

Leveraging the models generated by the MPC Toolbox,
the effort of simulating the system behaviour in unit tests isgreatly reduced. From this same model, a simulator can besynthesized and programming effort can now be re-directed
into writing verification of the MPC controller’s behaviourin the unit test framework. For example, a unit test could
setup initial conditions meant to drive heater outputs to theirmaximums, and then test that the boundary conditions in thedevice configuration:
1. have been passed to the model, and2. the heater output calculated by the model does not exceed them.

RESULTS
Previously, the setpoint temperature for the monochromators was controlled by manually adjusting the two heater outputs per monochromator until an equilibrium was achieved
around -180 ◦ C. The temperature changes over time weremonitored using the Karabo control system and occasionallyheater adjustments were made.
In Fig. 2, the temperature stability of the system over several hours can be observed, both before and after the MPC
regulation is activated. In addition, it is very difficult totune the system so that both crystal temperatures are exactly
the same since heater input from one crystal will eventuallyaffect the temperature of the other. Additionally, the temperatures will also vary depending on the power of the X-ray
beam passing though them.
The Karabo device based on the MPC toolkit wasdeployed to control two monochromator devices in theFemosecond X-ray Experiments (FXE) instrument in
September 2022. When the regulator is active, it is able
to bring the two crystal temperatures to the setpoint of 180 ◦ C within a few minutes and hold the temperature witha standard deviation of 0.006 ◦ C. A zoomed-in view of theregulator being activated is shown in Fig. 3. The process tobe controlled has quite a slow time scale, so it was sufficientfor the MPC to calculate and update the heater outputs once
every 10 seconds to get this result.
The constant parameters in the MPC formula were exposed as Karabo device attributes and were easily tunable
during testing to find ideal values. Once these values weredetermined, they were used by the software as device configuration for the unit tests. This allows the simulator to
respond the same way as the actual system would for oursoftware unit tests.
The overall result is improved temperature stability inthe monochromator devices. In addition, the simulator synthesized based on the same model use to synthesize thecontroller can be used to observe how the controller would
behave under any initial conditions defined in a software
test.

CONCLUSION
This implementation demonstrates that it is possible tocapture all the control logic of a high-level process control device into a software model using the MPC Toolbox.

TUPDP033581

Content from this work may be used under the terms of the CC BY 4.0 licence (© 2023). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

19th Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS2023, Cape Town, South Africa
JACoW Publishing
ISBN: 978-3-95450-238-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS2023-TUPDP033

Content from this work may be used under the terms of the CC BY 4.0 licence (© 2023). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

19th Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS2023, Cape Town, South Africa
JACoW Publishing
ISBN: 978-3-95450-238-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS2023-TUPDP033

Figure 2: Temperature plot of both monochromator crystals in ◦ C, showing the temperature regulation before and after theMPC is activated.

Figure 3: Temperature plot of both monochromator crystals in ◦ C, showing the transition with only a minor overshoot of
less than 10%.
Once the model has been synthesized, the effort of writing
a control system device is reduced to defining device configuration for the model’s constant parameters and writingcode to read and write attributes from other remote control
system devices. Additionally, the model is fully reusable forunit testing and simulation so there is no duplicated effort inwriting code to model the system behavior for the purposesof simulation or unit testing.
The resulting software device now serves as a template for
implementing a Karabo device to realize model predictivecontrol.

TUPDP033
582

REFERENCES[1] S. Hauf et al., “The Karabo distributed control system”, J.
Synchrotron Radiat., vol. 26, no. 5, pp. 1448–1461, Sep. 2019.
doi:10.1107/S1600577519006696[2] The Python Model Predictive Control Toolbox, 2023,
https://www.do-mpc.com[3] T. Middelmann et al., “Thermal expansion coefficient of single crystal silicon from 7K to 293K”, Phys. Rev. B, vol. 92,
p. 174113, Nov. 2015.
doi:10.1103/PhysRevB.92.174113[4] H. Sinn et al., “X-Ray Optics and Beam Transport”, EuXFEL,Hamburg, Germany, Rep. XFEL.EU TR-2012-006, Dec. 2012.

SoftwareControl Frameworks for Accelerator & Experiment Control