Software vendors
One integration reused across every compatible device
Reach a growing set of compatible hardware through one shared API and keep your own workflow, analysis and user experience exactly as they are.
- What you gain
- One integration reaches current and future compatible hardware from any vendor.
- What you implement
- Integrate the openDAQ SDK into your application once. Your workflow, analysis and interface stay as they are.
- First step
- Connect one compatible device to one customer workflow and get discovery, configuration and streaming working end to end.
The problem
The device-driver matrix grows faster than the team
Every device your customers own is a separate integration you did not want to write and cannot stop maintaining.
Sales blocked on hardware you have never seen
A prospect owns three instruments from two vendors. Two are supported. The deal waits on an integration nobody has scheduled.
Maintenance you did not choose
Each vendor's firmware release is a potential regression in your product that is discovered by a customer rather than by you.
Engineers write connection code instead of product
The people who should be improving your analysis spend their time writing yet another connection layer.
What changes
Integrate the model rather than the devices
You integrate openDAQ once. That integration then works with compatible device modules that already exist and with ones written after your release because your application talks to the shared model rather than to any particular device. Keeping the SDK current is ordinary dependency maintenance and not a new integration per device.
Devices you have never tested against
Your application works with current and future compatible hardware from vendors you have no relationship with.
One integration instead of a driver matrix
The per-device work collapses into one dependency and the regression surface collapses with it.
Your workflow and your interface
openDAQ supplies device access. Everything your users value in your analysis, your UX and your reporting stays entirely yours.
Architecture
Where openDAQ fits
It sits underneath your application as a device-access layer. Nothing above it changes.
Your user interface
unchanged
Your analysis and reporting
unchanged
Your openDAQ integration
the work you do once
C++ with the API also available through Python, C#, C and Delphi
openDAQ Core
common device and signal model
Compatible DAQ devices from any vendor
current and future
Adoption lifecycle
The adoption lifecycle
Prove it against one device and one workflow before widening the scope.
One device and one workflow
Pick a single compatible device and the customer workflow it serves. Get discovery, configuration and streaming working end to end inside your product.
Widen the capability
Map more of the property model into your interface, handle devices that expose less than expected and validate against several vendors' hardware.
Certify and keep current
Certify the application on the application track and treat SDK updates as routine dependency maintenance.
Function blocks
Function blocks if you want them
A function block accepts input signals, calculates or analyses and publishes output signals inside a full openDAQ SDK instance, which can be the device itself or your application. They are an optional reusable processing layer that is entirely separate from device access.
- Scaling, filtering, statistics and FFT without reimplementing them per device
- Outputs are ordinary signals so the next block or your application consumes them identically
- Configured through the same property model as everything else so your existing property interface already renders them
Function blocks are a processing layer. They are not a protocol and not a device-compatibility mechanism. You can adopt device access without ever touching them.
Named examples
Software already in the ecosystem
The full inventory, with verified capabilities and status, is on the community page
Built for a product lifecycle
What you are committing a product to
Stable API
Breaking changes are exceptional. When one is unavoidable the release notes highlight it and explain what product teams need to do to mitigate it.
2–3 releases a year
A predictable cadence that product maintenance can be planned around. Releases are published openly on GitHub.
Backward compatible
New applications are designed to work with older openDAQ devices. Applications kept current also work with newer devices and modules.
Apache 2.0 open source
The SDK is public and permissively licensed. The shareholder companies ship openDAQ across their new products.
Resources
Where to look next
Everything here is public and needs no account, membership or sales conversation.
Software vendors FAQ
The questions this decision usually turns on
Which languages can we use?
Do we need a new integration for every new device?
What if a device exposes less than our application expects?
How much work is the first integration?
How stable is the API and what happens when it changes?
Why should we invest in an ecosystem that has to keep growing?
Next step
Tell us about your application
Which devices your customers ask for, how many integrations you maintain today and what your workflow needs from the hardware. We will scope a first integration against one real device.