How to Test Your Control System Without a Full LINAC
ESTRO 2026 was held in Stockholm under the theme “Innovating Radiation Oncology Together.” At the Cosylab and Teledyne Healthcare roundtable session, the theme focused on improving innovation in digital radiotherapy platforms. The speakers consisted of Rok Štefanič from Cosylab and Bill Nighan and Mark Iskander from Teledyne Healthcare.
The session, titled “Keeping Up with Innovation: Accelerated Development and Validation of Radiotherapy Systems through Digital Twins”, discussed the long-standing issue confronting radiotherapy original equipment manufacturers (OEMs).
The issue is how to develop and validate a linear accelerator’s control system before the full machine is assembled and ready for testing, while reducing lead times for complete hardware integration.
Watch the full ESTRO talk
Get access to the complete ESTRO session and dive deeper into the discussion at your own pace.
Three major challenges for radiotherapy OEMs
Three challenges are impacting the development of future generations of radiotherapy platform technology, and they interact with one another.
First, there is an increasing breadth of engineering skills needed to develop a radiotherapy platform, which is a system of both hardware and software. In addition, developing a radiotherapy platform requires system design, real-time software, safety thinking, risk assessment, quality assurance (QA), validation and verification (V&V), and a working knowledge of clinical workflow.
There are few in-house development teams with all these skills. Second, time-to-market expectations are becoming more aggressive. OEMs want development cycles to shorten, but their systems still have to be reliable, maintainable and suitable for a regulated medical environment – and there are no shortcuts for this.
"By using simulators inside CI, every software change is validated automatically. All types of regression, interface, state-machine, and error-handling tests run continuously during development, which is what turns simulations from a convenience to an engineering method with traceability."
Missed the session? Watch it now
Watch the full ESTRO talk
Third, hardware availability remains a perpetual bottleneck. The full machine arrives late, prototypes are expensive and often discarded after use, and access to beam time is limited until the final stages of the project. Waiting for complete hardware is a solution that today’s markets do not allow for.
The definition of full-stack control in a treatment machine
Cosylab defines full-stack control-system design as the entire control hierarchy of a radiotherapy machine, from the clinical workflow at the top to device-level regulation loops at the bottom.
At the very top of the hierarchy reside treatment workflow, operator applications, treatment session management, configuration, reporting and integration with surrounding clinical or engineering systems.
Between the top and bottom, there is subsystem coordination among accelerator control, motion, imaging interfaces, dose delivery, safety, diagnostics, service tools, and device orchestration.
At the bottom of the hierarchy lie programmable logic controllers (PLCs), real-time control, field-programmable gate arrays (FPGAs), embedded software, device drivers, timing, data acquisition, and communication with hardware components.
What is critical here is that these are not three isolated layers. In a radiotherapy treatment machine, they must function collectively as a single, controlled, testable, and maintainable system.
Their collective capability is due to system-level understanding, reusable medical-grade building blocks and a clear pathway from architecture through implementation, validation and verification, and commissioning.
First simulators, then continuous integration
The most pointed question raised during the discussion was: how do we test control system behaviour before the hardware arrives?
Cosylab’s solution is to use simulators that allow the control system software to interact with the representational subsystem’s behaviour even while the physical machine is being assembled.
Subsystems such as e-gun drivers, solid-state modulator, accelerator feedback controller (AFC), vacuum and motion can be modelled at any fidelity. On the one hand, simulators can be very simple interface stubs; on the other, they can be comprehensive models that realistically emulate device behaviour.
Either way, software engineers do not have to wait for the hardware to perform meaningful integration work.
"Even with extended sourcing timelines sometimes required for key components in the first article of a new linac system, simulation enables continuous development.
By advancing design and validation ahead of hardware delivery, customers have significantly accelerated progress by several months and reduced integration risk."
Using simulations brings three benefits. One is earlier integration because interface issues become visible sooner. The next is reduced dependence on prototype hardware, which is expensive, scarce and often shared among multiple teams vying for access.
The last is repeatability, since simulation allows scenarios including abnormal cases and edge conditions to run repeatedly without the overhead of setup. The step change comes when a simulation is incorporated into continuous integration.
The lead times for components used in building a linear accelerator are months, not weeks, a fact about hardware procurement that often surprises observers outside the field.
When hardware becomes an observable subsystem
In Teledyne Healthcare’s development approach, the data side comes from the company’s DS2 controller — its solid-state modulation platform — which is designed to supply the control system above it with information about what is happening within the hardware.
"The DS2 controller provides over one hundred data points per pulse. All of that is captured and made available to the simulator.
We can also digitise the last one thousand pulses, so real pulses can be played back inside the simulation."
With the DS2’s emulator mode, integrators can bring up the controller interface and develop bidirectional communications without having the power electronics present. For teams working independently but sharing the same procurement timelines for their hardware, this provides a real reduction in dependency.
Meanwhile, from a control systems perspective, the practical implication is that the DS2 stops looking like a black box and begins functioning as an observable subsystem, with three direct results. A simulator can be built around the same interface and its expected behaviour.
Testing of control system integration can occur earlier than previously, including verification of states, alarms, faults, and recovery cases. Finally, all these scenarios can be folded into automated tests within CI pipelines.
From today’s telemetry to tomorrow’s preventive diagnostics
The closing part of the discussion turned to the future. If a defined hardware interface, combined with a simulator and CI, provides OEMs with a faster, disciplined development process today, what will the same foundation enable in the future?
It will represent a viable pathway to predictive diagnostic capabilities using machine learning (ML).
However, the “recipe” is not just to bolt AI on top of an existing machine but to capture usable telemetry information from an observable piece of hardware, identify the most relevant patterns, verify the latter using a combination of simulation and testing, and finally apply machine learning techniques to detect early warning signs of degrading hardware performance.
The result will be a system that provides robust, proactive diagnostics.
While there is already more than enough telemetry available on a system such as the DS2 to overwhelm a human operator analysing the collected information, it is exactly ML, applied with discipline, that can make sense out of the mountains of telemetry.
Operationally, the ultimate goal is to improve the speed of detecting developing issues within the system, deliver more targeted maintenance, and increase overall system availability across the installed base.
Both sides of the panel made it clear that we should not treat the above as a marketing claim. The initial step should always be to establish the necessary data foundation upon which subsequent layers, including diagnostics, can be added.
Panel Conclusions
The main lesson learned from the discussion is that OEMs need to develop more quickly, without delaying integration and reliability issues until later, and to be able to use a wide range of engineering skills, since a radiotherapy platform will include both hardware and software.
They must handle system engineering, control software, safety thinking, risk management, QA, integration, testing, and understanding the clinical workflow.
Even as market-ready timelines grow increasingly aggressive, with shorter development cycles, OEMs still need a system that is reliable, maintainable, and suitable for a regulated medical environment. This is exactly where software architecture, simulators, and automated testing can help out.
The Cosylab radiotherapy control system offering is described on the RadOnc solutions page. For a joint technical consultation on simulator-based development, DS2 integration, or the path from telemetry to ML-based diagnostics, contact Rok Štefanič at Cosylab and the Teledyne Healthcare team.
About the speakers
Mark Iskander
Mark Iskander is Product Design Authority for Pulsed Power Subsystems within RF Power at Teledyne e2v, part of Teledyne Healthcare. He is an experienced product design authority and technical leader with extensive expertise in pulsed power subsystems, high-power RF systems, power electronics, and system integration.
Bill Nighan
Bill Nighan is Vice President of Business Development for Teledyne ETM’s High Energy X-Ray (HEX) business, part of Teledyne Healthcare, which provides MV X-ray generating products and integrated solutions to all of the world’s leading OEM customers in the radiotherapy and industrial markets.
Rok Štefanič
Rok Štefanič is Cosylab’s Senior Medical Systems Architect and is responsible for system architecture and design of software control systems for proton and radiation therapy machines. Rok has a clear understanding of the underlying hardware, and he focuses on finding optimal, reliable solutions tailored to complex medical environments.