The imaging chain
What's inside an OEM ultrasound engine?
The term describes a subsystem, rather than a single chip or a guarantee of a particular imaging mode. A typical engine includes the following parts. The scope supplied by an OEM partner must be specified.
Transmit and receive electronics
Transmit timing and drivers excite the probe. The receive analog front end provides protection, low-noise amplification, time-gain control and analog-to-digital conversion. Transmit and receive electronics have different jobs and may be supplied as separate modules.
Beamforming
Receive beamforming applies delays and combines channel signals to focus on locations in the image. Transmit focusing, steering and acquisition sequencing are separate requirements that must also match the probe.
Signal and image processing
Filtering, demodulation, envelope detection and scan conversion support B-mode imaging. Doppler and advanced methods need their own acquisition sequences and processing. Their availability and performance are configuration-specific.
Software and interfaces
Control APIs, configuration tools and data interfaces connect the engine to the host application. Research RF or IQ access must be agreed explicitly: raw channel data, beamformed IQ and a displayed image are different outputs with different bandwidth demands.
Why integrate an engine?
An OEM engine can let a product team reuse an imaging architecture while focusing on its application, enclosure and clinical workflow. The trade-off is integration work: probe compatibility, software interfaces, performance verification, production continuity and the responsibilities of each supplier still need to be established.
Medical-device clearance applies to the finished product and its intended use. An engine or an engineering service does not automatically give the resulting device FDA clearance, a CE mark or an ISO certification.
Architecture choices
FPGA vs. GPU beamforming
Both can perform beamforming. A hybrid design assigns work according to timing, data transfer, power and software needs; the split is not universal. ALEVA's beamformer engineering uses an FPGA/GPU architecture.
| Consideration | FPGA | GPU |
|---|---|---|
| Common role | Acquisition control, data movement, deterministic processing and receive beamforming | Parallel beamforming, reconstruction, advanced processing and AI workloads |
| Engineering strength | Custom pipelines and predictable timing | Programmable processing and iteration in software |
| Integration constraints | Logic resources, interfaces, firmware verification and power | Host transfers, memory, scheduling, power and thermal limits |
| What to measure | Timing accuracy, sustained throughput and latency | End-to-end throughput and latency, including transfers |
A GPU does not recover information that was discarded before it receives the data. Decide early which channel, RF or IQ information must be retained for the intended imaging modes and research work.
Match the engine to the probe and product
Element count alone does not define a system. Record active transmit and receive channels, multiplexing, probe frequency and bandwidth, connector pinout, drive limits, acoustic requirements, and receive sensitivity. A handheld product also needs a realistic power, thermal and data-link budget.
| Area | Specify |
|---|---|
| Probe and acquisition | Probe geometry, channel counts, supported transmit sequences, timing reference and calibration |
| Imaging output | Required modes, depth, field of view, frame rate and acceptance criteria under stated conditions |
| Data access | Raw RF, channel IQ, beamformed IQ or image output; sampling, metadata and sustained interface bandwidth |
| Product integration | Host platform, APIs, dimensions, power, thermal limits, updates and serviceability |
| Verification and transfer | Test evidence, deliverables, manufacturing responsibilities, documentation and licensing terms |
ALEVA's iProbe program covers custom probe and transducer engineering. The OEM engineering scope connects probe integration, electronics, beamforming, software, prototyping and manufacturing transfer. Available configurations and deliverables are agreed for the individual project.
From probe to product: the integrated engineering scope
An OEM engine is one layer of a project-specific development program. The agreed scope can also include probe and transducer engineering, system electronics, software, industrial and mechanical enclosure design, verification records, regulatory documentation support and manufacturing transfer. Finished-device regulatory responsibilities and acceptance criteria must be defined separately; documentation support does not guarantee approval.
From requirements to integration
How an OEM development program works
- Define the application. Establish intended use, probe, modes, host, budget and measurable acceptance criteria.
- Specify the architecture. Assign acquisition, beamforming and processing responsibilities, including the data interfaces and calibration.
- Build and verify the prototype. Measure imaging, timing, bandwidth, power and thermal behavior against the agreed requirements.
- Prepare the transfer. Agree production tests, engineering documentation, software maintenance, manufacturing transfer and finished-device regulatory responsibilities.
Explore the OEM development guides
Frequently asked questions
OEM ultrasound engine questions
What is an OEM ultrasound engine?
It is an imaging subsystem that combines echo acquisition, beamforming, and signal and image processing for integration into a device maker's own ultrasound product.
What's the difference between an engine and a beamformer?
The beamformer focuses and combines probe channel signals. The engine is the broader subsystem around it, including acquisition electronics, processing, control software and interfaces.
Can an OEM engine be matched to a custom probe?
Yes, when its channels, frequency range, timing, transmit drive and receive interfaces meet the probe's requirements. ALEVA offers custom probe engineering through iProbe; the integration scope is agreed for each project.
Does the engine provide raw RF or IQ access?
That depends on the configuration. Raw channel RF, channel IQ, beamformed IQ and image data are different outputs. Specify the required output, metadata and transfer bandwidth in the project requirements.
Does an OEM engine include regulatory approval?
Not automatically. Engineering documentation can support the finished-device submission, but clearance, certification and clinical validation must be established for the particular device and intended use.
Can we start with a board and later transfer the design?
Board supply and technology transfer have different engineering deliverables, intellectual-property rights and support obligations. Discuss the intended supply and transfer model with ALEVA before choosing a configuration.
Ask for an integration acceptance record
Define acceptance at the engine-to-host interface. Identify the probe, acquisition sequence, output type and host configuration before comparing an OEM ultrasound engine. Raw channel RF, channel IQ, beamformed IQ and image output need their own interface definitions.
Our proposed record includes the hardware, firmware and software revisions; sample format and units; channel order; event identifiers; timing reference; calibration revision; test conditions; acceptance limits; results; and unresolved items. This is a record template, not a completed test report.
Measure the required workload from acquisition to the agreed output boundary. State whether transfers, buffering, processing and display are included. Report capture loss and incomplete outputs alongside latency and throughput; distinguish a short burst from sustained operation.
NVIDIA's Holoscan Sensor Bridge 2.7 architecture describes different host-receiver paths, including RDMA on suitable hardware. It illustrates why the actual transport and host belong in the evaluation record. Architecture reference.
Use the FPGA/GPU architecture guide for partitioning decisions and the OEM service scope to agree deliverables.
Define an engine that fits your product.
Share your probe, required modes, data access and host platform with our engineering team.
Discuss your project →Explore the complete program: turnkey ultrasound device development →
Read more engineering articles →