ALEVA

Ultrasound Engineering

Ultrasound OEM software verification starts with a reproducible release baseline

A practical checklist for tracking firmware, GPU software and acquisition settings when evaluating changes to an ultrasound imaging pipeline.

Record the system, not just the application

An ultrasound software version does not fully identify the system that produced an image. Acquisition firmware, configuration, reconstruction code, processing libraries and calibration all belong in the test record. For a GPU-based processing path, record the GPU model, driver, runtime and SDK as well. Retain the build identifier and a reference to the exact test dataset.

This is a design recommendation, not a description of ALEVA's confidential implementation. The aim is to make comparisons interpretable: a changed image should be traceable to a controlled change rather than an undocumented software environment.

Use current releases as evaluation candidates

NVIDIA published Holoscan SDK 4.6.0 in September 2026. Its public release notes list dependency changes, fixes and known limitations. This is an example of why an OEM team should review release documentation before upgrading its processing environment. Neither the release nor this article establishes the performance, medical suitability or regulatory status of an ALEVA device. NVIDIA release notes

Separate reconstruction checks from acquisition checks

Replaying an unchanged RF or IQ dataset can help compare reconstruction software. Define what is being compared: intermediate numerical outputs, reconstructed images, timing boundaries or error handling. Establish appropriate numerical tolerances; do not assume different GPU environments must produce bit-identical output.

Replay alone does not test the live probe, analog front end, clocking or acquisition transport. Run a separate live-system verification under the same documented operating conditions. Include incomplete input, configuration changes and recovery after a processing failure in the test plan.

Make release acceptance explicit

Before development begins, agree on the reference configuration, representative datasets, acceptance limits, regression tests and records to retain. A successful demo is not a substitute for that agreement. Keep engineering observations separate from clinical claims and any regulatory assessment required for the intended product.

ALEVA, based in San Jose, California, USA, supports ultrasound OEM development and beamformer engineering. These release-baseline questions can be included when defining a custom ultrasound program; no use of a particular third-party SDK in an ALEVA commercial product is claimed here.