Device vendors
Expose your device through one shared model
Compatible applications can then discover it, configure it and stream measurement data from it without you writing a driver for each one. That holds for a rack instrument and for a constrained device that streams over openDAQ Streaming LT alike.
- What you gain
- Every compatible application can discover, configure and stream from your device without a driver written for each one.
- What you implement
- One device module that maps your hardware into the openDAQ model. It runs on the device or on a PC beside it, so your firmware stays as it is. A device on a real-time operating system can use the openDAQ LT C stacks instead.
- First step
- A prototype with enough device structure for discovery and basic streaming. It usually takes a few days.
The problem
The driver matrix is the product tax nobody budgets for
Every application your customers want to use is a separate integration and each one has to be maintained for as long as the product is sold.
Every application is its own project
A customer asks for support in an analysis package you have not integrated with. That is a specification, an implementation, a test cycle and a support obligation repeated per application.
Customers buy your hardware and not your drivers
Customers choose your device for its signal conditioning, accuracy, isolation and ruggedness. Connection code does not win sales. It still takes time from the engineers who build those strengths.
Losing deals on a checkbox
A perfectly good device loses to a worse one because the customer's software already talks to the other vendor.
What changes
One implementation reused by everything compatible
You write a device module once and it maps your hardware into the common openDAQ device and signal model. Every compatible application then reaches it through the shared API including applications that do not exist yet. openDAQ adds a reusable access layer on top of your product. It does not obscure what makes the product good and it does not require you to open your firmware.
Every compatible application from one integration
Your device becomes visible to the whole ecosystem the day the module works including software vendors you have never spoken to.
One codebase instead of a driver matrix
The per-application integration work disappears and so does the regression testing that came with it every time an application released.
Your hardware, your firmware and your IP
The module is a mapping layer. Your signal path, calibration and firmware stay yours and you decide which capabilities to expose.
Architecture
Where openDAQ fits
The device module is the compatibility implementation you create. It can run on the device itself or on a PC beside it so it can usually be added without redesigning your firmware. Function blocks can run on the device as well so your product delivers processed results and not only raw data.
Compatible applications
analysis, automation and recording
openDAQ Core
the shared model on your device and in every client
Your device module
the work you do once
Your function blocks
optional processing on the device
Runs on the device or on a PC beside it
Your hardware
channels, signals and firmware
Your calibration
unchanged
Adoption lifecycle
The adoption lifecycle
Prototype
Expose enough device structure to establish discovery and basic streaming. Usually a few days and it is what makes a real estimate of the full implementation possible.
Implement and validate
Extend to the configuration and synchronisation capabilities you want to support with guidance if required and validate against real client applications.
Certify and maintain
Certify the product against the four device checks and then recertify only when the product changes or a release changes tested behaviour.
Protocol integrations
You may not need a device module at all
A protocol integration maps a supported protocol and profile into the same common model. Where your product already implements one of them, that shared mapping can carry it into the ecosystem.
- Products speaking a supported protocol such as OPC UA or ASAM CMP may reach openDAQ through an existing integration
- You gain a shorter path in and give up control over exactly how your device is represented
- A product-specific module is still the route to full configuration and synchronisation capability
Protocol-based compatibility depends on the specific protocol, profile and capability your product implements. It has to be identified and verified per product. Implementing a named protocol does not by itself guarantee full compatibility.
Named examples
Hardware 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.
Device vendors FAQ
The questions this decision usually turns on
How much time will implementation take?
Do we have to rewrite our firmware?
Can our device process data before it streams?
Does open source mean giving away our product IP?
What if our device cannot host the full SDK?
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
Bring us your device
Tell us what it is, how it currently connects and which applications your customers ask for. We will tell you what a module would involve and whether a protocol integration gets you there faster.