PT Software – Safety Systems
Evolving Role of Software
Common sense states that the importance of software (SW) cannot be understated in the safety-critical aspects of a PT machine. Jay Flanz steps in and shares his opinion on the matter.
Jay sees the critical role of software in PT as an evolving theme in his life over the last few decades. But he believes we should start our considerations from the observation that, fundamentally, a non-working machine is not a safe machine, as the patient is not getting any treatment.
In the early days of the development of particle-therapy machines, the role of software in safety was not central, as the domain demanded tertiary or even higher redundancy. Using “wires and AND gates” was deemed more reliable, with control logic being “more tractable”. At that time in the PT industry, it was never acceptable to use software to mitigate severe hazards or highly probable faults.
To play the devil’s advocate, why was this so? Isn’t it true that software runs the way it is written, including all of the implied timing issues and integration issues that might be built into it? If there are reliability problems with software, it is not a generic trait of its technology, but it means either that the SW wasn’t written well or that there are variables in how it runs which aren’t explicitly embedded.
Accelerator Engineers are often not the best SW Designers
Due to a combination of some confusion and lack of understanding, software in PT evolved into something that was never fully embraced by control systems engineers for managing and supervising safety in PT machines.
The quality of the software is a function of how good the SW architects are and how well they’ve incorporated what’s essential in the design of their system. Historically, people who were good at devising accelerator control systems often did not excel in planning sophisticated software. Good accelerator engineers always knew how to set magnets and turn on the beam, but they didn’t necessarily know how to understand all the embedded implications of the software control system.
When particle-beam scanning came about, control software became even more critical, especially pertaining to safety measures and procedures. When you needed to perform an analysis or enable handling of statistics, noise and glitches without unsafely stopping, you couldn’t just have the option of a binary stop.
“Software for safety could be used similarly to the anti-missile system Iron Dome”
With the latter, you would never finish the treatment — it could be part of a two out of three logic, or it could have been employed to decide that something is safe, even if you thought it wasn’t, or vice versa. Jay points out this as an excellent example of how error handling in PT has been a much-ignored topic through the years.
Jay feels that it’s never really been done well by most people building PT control systems to his knowledge. On the other hand, it should be performed by developers that know and understand software architecture, design and development. Jay adds that he has concluded that software for safety could be even more effective if used similarly to the anti-missile defence system Iron Dome, a skeleton framework on the outside that independently watches what’s going on.
Software and Medical Standards
Uros Mitrovic agrees with Jay that software plays a progressively more vital part in PT safety systems subunits. So going from the “traditional” way of guaranteeing safety in PT, many control measures have been implemented in software as time goes by. For instance, with the recent introduction of artificial intelligence (AI) such as image registration algorithms for IGRT (Image-Guided RadioTherapy), controls engineers can enact risk-control measures purely in software.
To rely on software to irradiate patients safely and effectively, you need to have reliable and well-written software. And to create the latter, you have to follow a heap of medical standards meticulously. So software development for a particle therapy system is complex because it demands excellent software design capabilities combined with a deep understanding of the PT domain.
And all the relations between the multitude of devices, subunits and processes have to be strictly defined. Risk management plays a central role in the system as a whole and needs to be thoroughly and well tested, from the unit to the system level. That means that you must have unit tests, code reviews, static analyses, unit integration tests, system integration tests, workflow testing, end-to-end testing, and, finally, V&V (Verification and Validation). All of the latter can prove your software is safe and efficient to be used in the proximity of patients and personnel.
If you’d rather listen to the above, watch the video clip from the round table:
Read the rest of the series …
This is the third article in a series of blogs dealing with the challenges of developing good software for particle therapy systems and is based on the PTCOG 59 round table “SOFTware: the HARD part of proton therapy“.
- Part 1: “PT Software – The importance of subsystems integration for machine performance“
- Part 2: “PT Software – Why do Radiation Therapy and Particle Therapy machines differ so much in the control-room design“
- Part 4: Next time, we will look at PT system upgrades and the contribution of software to PT improvement.
ABOUT THE PANELISTS
Subscribe to our newsletter
What kind of content are you interested in?