Introduction
Ultrasound has become a powerful tool for medical diagnostics, but as systems become more advanced, so do the challenges faced by start-ups or researchers looking to commercialise a novel ultrasound concept. This is largely down to the following reasons:
- Limited access – Off-the-shelf ultrasound systems rarely provide transparency into design decisions or access to the underlying architecture, limiting the ability to use them as a starting point.
- Integration difficulties – Most commercial ultrasound systems are not flexible enough to allow easy integration of new hardware or software ‘inside the box’.
- Limited collaboration culture – Traditional ultrasound vendors have not typically focused on R&D partnerships, particularly those using unconventional imaging strategies.
- Economic barriers – Many ultrasound manufacturers prioritise selling large numbers of finished systems, with limited scope to back novel concepts with large development costs and uncertain rewards.
One answer to this is to build your own system from the basic components. But to make software development feasible, you need first to have defined your hardware setup. This reduces the flexibility of the whole design, making it more difficult to balance trade-offs in reliability and performance, and increasing the risk of numerous frustrating iterations before reaching a working prototype.
Building on our experiences developing such systems, TTP recognised the need for a platform to address these challenges and set out, with our collaborators at Smart Acoustics, to build a software-defined ultrasound (SDU) system.
Working together, we set out to turn the initial idea into a modular, scalable platform that would make it much easier for development teams to turn their ideas into a manufacturable product design. The journey hasn’t been easy, but it has provided valuable lessons in ultrasound architecture, modular design, and the realities of building flexibility into complex systems – insights we share below.
Developing the SDU concept
One of the reasons we were particularly interested in this project was that it had the potential to address a challenge that we’d encountered with ultrasound projects for other clients – the need for a full hardware redesign, even when the underlying signal-processing principles were similar.
Separately, we realised that the architecture of a system we had previously created for a particular project could, if parametrised, be scaled arbitrarily to however many channels were required. We termed this concept software-defined ultrasound (SDU), by analogy to software-defined radio, whereby much of the signal processing is done by a general-purpose processor, rather than being performed in dedicated electronic circuits.
The idea behind SDU was to replace fixed, hardware-bound architectures with a system that was re-programmable, scalable, and open to experimentation.
This SDU concept, we realised, hinged on two principal features:
- A modular system design to provide the necessary flexibility for a wide range of applications.
- An application programming interface (API) to provide a control mechanism for these transducers, whatever their configuration.
With experience from multiple ultrasound projects, we were confident in our combined expertise in hardware design, signal processing and imaging, as well as in our understanding of the need to develop a system with these features at the core.
Transforming the SDU concept into a practical, scalable platform ready for real-world use proved more complex than expected, with each engineering problem solved revealing further layers of complexity.
And yet this intensive engineering journey has proven valuable, pushing us to innovate and work at the boundary of what’s possible. The result is a system that now represents the state of the art. To understand how it was achieved, we examine eight of the key challenges we faced in developing a truly modular SDU.
1. Setting up a modular system for channel flexibility
To realise our vision for a truly versatile ultrasound platform, we first needed to move away from a system where standard 128- or 256-channel modules are bought in as ‘fixed’ components of the design. These days, engineering teams want versatility in how they drive transducers and receive data – for example using fully-addressable systems to explore new beamforms using custom probes, carry out plane-wave imaging, or use AI algorithms on the raw (rather than post-processed) data.
We realised that this versatility would be useful not just from one project to another, but even within projects. For example, if you start off implementing your concept on a monolithic 128-channel system, but then realise that there are benefits to expanding it to 256 channels, you don’t want to have to redesign your whole system from scratch. Similarly, you might start at the standard 128, but be interested in how the imaging performance changes if you scale down to 64 channels.
This led us towards devising a truly modular setup based on a ‘stackable’ 16-channel unit, with a core invariant design fitted into an architecture that can scale almost arbitrarily and completely transparently. In this way, it becomes possible to expand the number of channels easily, from 16 through the standard 128 up to 512 or even more – yet still drive them as a single system. At the same time, the system’s flexibility extends to the data, because it is defined by software, not baked-into the hardware.
The question then became, how could we integrate these modules so that they all work together in unison? We first needed to establish a group-based architecture that enabled modules to be added easily, and that allowed each one to ‘know’ where it sat in the system. When doing this, we made sure to write the software so that we weren’t embedding assumptions about the size of the system. That was straightforward enough, but the second aspect presented more of a challenge – synchronising the clocks.
This highlighted that scalability is not just about adding channels, but about designing architectures that remain coherent and adaptable as system size changes.
2. Achieving precise control by robust inter-module synchronisation
For medical ultrasound systems to function properly, it’s vital that all the components are perfectly synchronised with each other using a carefully considered distribution of clocks, and that communications are tightly controlled. This need also extends to every component within the SDU, not least because any mistiming between modules would result in an unusable ultrasound beam. Accordingly, we needed to ensure that both the pulses sent out and the data received back were aligned to a known reference point.
Achieving this for our modular system was not straightforward, because of the independence of the individual units. But we realised that delegating the synchronisation protocol to the baseboard (or indeed, a level higher) meant that communication between the modules could be reduced to the bare minimum (e.g., information on the board number, or which modules are present). This in turn meant that the presence or absence of a module would be irrelevant to other modules, allowing the whole system to be easily scaled up.
We hard-coded that into the system, and we found it worked very well – but the very fact that it couldn’t be changed was a barrier to achieving a truly versatile SDU. So, we rapidly moved towards a next generation, in which we placed a field-programmable gate array (FPGA) on the baseboard, enabling us to easily reprogram how the boards were ‘talking’ to one another. This had benefits for our SDU by opening up another dimension of flexibility – specifically, enabling multiple baseboards to be connected together, and allowing more complex but precise synchronisations both within the SDU and with any external function that a client might need to build onto it. But it still wasn’t quite good enough.
Nevertheless, the experience reinforced that early synchronisation decisions can either enable or constrain future flexibility, making them a critical architectural choice rather than an implementation detail.
3. Enabling architecture versatility for complex probe arrangements
Although we’d incorporated an FPGA on our SDU baseboard to achieve synchronisation, on another project (a 128-channel setup) we needed to allow ‘unconventional’ imaging strategies. This meant having control over individual channels within an acquisition run, in order to build architectures that weren’t based solely on the 16-channel base module. This pointed towards the need for a software-controlled switch array, with a switch on each channel – but, frustratingly, the baseboard we were using didn’t have that facility.
So rather than upend our SDU design and use a different baseboard, we reconfigured the system so that Board 0 controlled the switch array, but with the signals now routed via the baseboard, in order to ensure synchronisation – which worked very nicely. We also adjusted the API so that it could easily accommodate an arbitrarily complex arrangement of probes – flexibility that we believed would prove very useful for future projects.
An alternative strategy that we’ve developed for a recent project involves interfacing the SDU with an external block, which uses the synchronisation signals from the baseboard to control when acquisitions happen. Through the use of ‘flags’ raised at the start of an acquisition and lowered at the end, it also allows progress to be monitored by the external block without it having to assimilate the detail of what’s going on.
Although this modified system did require some extra software to ensure it was robust, it’s simple and works beautifully for this particular application, allowing more channel control without committing to a fully bespoke system. This was useful because when a client needed to demonstrate that their innovative ultrasound imaging concept was going to work in practice, before devoting resources to refining the architecture.
Nevertheless, for the time being, we’re using the ‘Board 0’ solution within our SDU, because it does virtually everything that we need it to. But it’s still useful to have the ‘external block’ solution if needed, and in the future, we plan either to integrate it completely, or revisit the possibility of using a new baseboard with greater channel-control capability.
Get the full e-book:
Drawing on several years of engineering work, get the full e-book to read about the practical insights that may be useful to teams designing new ultrasound systems or exploring alternative imaging approaches.
- The learnings on building a genuinely modular ultrasound system
- Maximising performance through persistent troubleshooting
- Optimising usability through understanding user perspectives
- Iteration, integration and productisation
