Accelerator Control Systems in research environments have always faced a dilemma of user expectations. The ultimate goal for management is to have a user press a single large button, the only button in the control room, and have the system produce tuned beam, delivered to target.
But a common desire of end users – the Physics or Research staff – is to have dozens of buttons, dials, gauges and monitors with which hours of finely tuned adjustments can be spent to perfect the quality of the beam.
The development of control system software often wants to satisfy both goals. Providing support for as many user interaction points as those users want, while supporting high-level algorithm development for automated control.
I’d like to consider how this relates to clinical accelerators, specifically larger proton machines in a clinical environment for oncology.
The Need to Tweak
The modern base of the software effort for user interaction seems to be the configurable display manager which provides the end user with what can be called a dynamic drawing tool. A set of graphical elements can be customized and drawn on a screen, and then associated with actual input or output channels to the equipment. They can also be attached to high-level algorithms interacting with the equipment. This satisfies the need to tweak multiple settings, examine any number of measured values and in some cases, to show off the artistic talents of the engineering team.
The need to tweak the machine sometimes leads to a desire to tweak the look of the control software. Associated tools offer similar configuration options for the purpose of managing alarms, displaying plot data, correlating events with log file entries and more. These additional tools are ideally integrated to some extent with the display manager, but allow varied color schemes and layout options.
A wealth of configuration options and presentation choices will encourage each person to provide visually distinct interface screens. The resulting control room can provide inconsistent views of the system. Industrial control systems have similar tools and can offer even more customization as commercial products. They will offer functionality similar or superior to modern accelerator control software but might not provide support for the specialized equipment or processes found in accelerator systems.
Why is This a Concern?
This all sounds fine, what’s the problem?
There are commercial accelerator systems where minimal control interaction is expected. This includes accelerators for medical use such as the oncology systems mentioned above. These vendors typically want to provide a product with no accelerator control room and basic user interface software supporting non-technical, clinical users.
A traditional Radiation Oncology product uses a small electron accelerator housed in a physical enclosure, similar in size to a modern CT or MRI machine. Technically less complex than a research accelerator, there’s simply no need for a control room or the configurable control software mentioned above.
Proton Therapy is a more recent modality of radiation oncology, with a much larger accelerator producing much more energy than those traditional systems. A multi-room proton therapy center might contain a cyclotron, synchrotron or linear accelerator with over 100 meters of beamline. Such a system will require substantial control system software, but there are different goals.
If a clinical user is given access to certain high-level features of accelerator control, the human interface needs to be aligned with their perceptions of the system, their terminology and expertise, and it needs to be consistent in color, texture and usability. The interface needs to be accommodating to people who are not accelerator experts.
So why is it important to provide accelerator control access to clinical users?
An Ideal Solution for Cost Reduction
An important part of the proton therapy product is a service contract, but the vendor will typically not want to provide on-site accelerator experts or operators. To keep costs down, these experts will be presented to customers as Service Engineers, ideally working away from the system in a central location, able to access and maintain multiple customer sites remotely. Similar to a Network Operations Center, this solution allows for some of the knobs and dials that technical people want, while keeping costs down for management.
Locally accessible spares are still crucial for the customer and a service engineer will occasionally be required on-site for work as needs arise. An on-site accelerator control room would rarely be used and not cost-effective, but a solution is needed for those on-site visits for repair or maintenance work.
A laptop or portable device can provide access while on-site, but will be cumbersome to use given the functionality of a fully-featured accelerator control room. To make the best use of available resources, the Service Engineer could use the equipment within a treatment control room, ideally including multiple large monitors, keyboard, mouse and so forth.
However, there are issues that can arise that cannot be addressed remotely, but are small enough to be addressed quickly and safely by an untrained user.
A More Practical Solution...?
In practical terms, there are clinical sites hesitant to offer direct remote access for service support. Also, a central operations hub for accelerator controls might seem like a great idea for accelerator experts, but with reliable, well designed accelerators and robust control software, it might not be necessary.
A more realistic solution might be to simply provide remote access to individual service experts when support is required. Customer confirmation could enable remote service connections. But in any scenario, having a clinical person access some form of accelerator controls on-site is an important feature.
Consistent Accelerator Controls Interaction
Both clinical and accelerator experts will benefit from a more controlled and consistent user interface to the accelerator control system. In technical terms, I equate this to the differences between user interactions on Linux and Mac computers.
People with technical backgrounds enjoy Linux-based systems because they are able to adjust any color, any button or graphical widget on the screen. They can change the way applications are accessed, and each app can even have its own color scheme, menu system and specialized sets of commands.
People with less interest in the computer itself, who typically focus more on specific non-computer tasks are happy with MacOS interaction that is more restrictive in its options. Buttons and graphical widgets are always the same although color schemes and basic aspects can be adjusted.
More importantly, on MacOS the interactions are consistent across applications. The same keystrokes are used to access a file, to print or to adjust preferences, and the menu selections for those functions are in the same place on the top menu bar in any application.
This type of user interface consistency is needed for clinical proton accelerator control systems.
In many ways, this is already important for product development in general. As a vendor, we need most components, including software, to be the same for all our customers, rather than having custom components for different sites.
In technical software terms, configuration files should be replaced with settings made directly in the software. If editable configuration files are important, they should be restricted to access only by authorized experts.
Since the accelerator is associated with a medical device at each customer site, regulations might require revalidation of certain components when changes are made to the operating environment. In other cases, a formal analysis might be required indicating why a revalidation is not necessary.
Role-based User Interactions
Rather than having preferences set for each user, the control system (both accelerator and treatment controls) should provide adjustments that affect all users. Having one login account displaying text in French while another displays English will cause problems when unexpected situations arise.
Instead, preferences and adjustments should be specific to each type of user, specific to the roles those users play. For the clinical user, selecting a button named “Reset the Proton Beam Delivery System” is preferable to a button labeled “Start Degauss BL3::Dipole2”. A service engineer would expect to see that detailed kind of message, and will often need to see both labels to understand the user’s situation when troubleshooting a problem.
Imagine an on-screen display of equipment adjustments that highlight elements in red when out of range; although the quality of the beam isn’t affected, a clinical user could see this as an issue with the treatment itself.
In fact, the goal is to provide the clinical user with the same look-and-feel to the controls interface as seen in the clinical treatment interface. The clinical user needs to see an integrated treatment system, not a display telling them about twenty systems connected together behind the wall of the treatment room. It would be great if they never see text that indicates that a “connection lost to delivery nozzle” or “LLRF network node reconnected.”