System integrators
Deliver mixed-vendor systems with no one-off adapters
You build the test systems other people run. Where the products in them are compatible the connections stop being custom work you own forever and the application on top is one integration instead of one per device.
- What you gain
- Mixed-vendor systems are assembled from compatible products instead of wired together with one-off adapters.
- What you implement
- Your application integrates openDAQ once. A product that is not compatible yet needs a device module or a protocol integration whose protocol, profile and capability are verified for that product.
- First step
- A pilot on one real rig with at least two vendors that checks discovery, configuration, streaming and the shared time base.
The problem
Every project rebuilds the same glue
The specification changes, the vendors change and the integration work starts again from close to zero.
One-off adapters become your liability
The one-off connector written under delivery pressure is what you are still supporting in five years and usually without the engineer who wrote it.
Commissioning eats the schedule
Finding devices, configuring them consistently and proving they share a time base is slow when every product does it differently.
Lock-in by accident
Standardising on one vendor to avoid integration cost trades a technical problem for a commercial one.
Automation that breaks on contact
Scripts written against one vendor's interface do not survive the instrument being swapped and the system you handed over stops being maintainable.
What changes
Assemble from compatible parts
When the products in a system speak the common model the system is composed rather than wired. Discovery replaces manual addressing. Self-description replaces per-device configuration code. The time base becomes something you verify rather than assume.
Specify the best product rather than the compatible one
Choose instruments on measurement merit rather than on whose software already talks to them.
No one-off device adapters
Where products are compatible the integration layer is already written, tested and maintained by someone else.
Maintainable systems and real optionality
Handover is a documented system rather than a folder of one-off code and swapping a vendor later stays possible.
Architecture
Where openDAQ fits
It is the layer the system is assembled on and it spans products from different vendors in the same rack.
Client applications
analysis and automation
Your delivery tooling
commissioning and test scripts
openDAQ Core
discovery, configuration, streaming and time
Device modules
vendor-supplied
Protocol integrations
shared mappings
Protocol integrations
for products on other buses
Written once by whoever owns the product rather than by you per project
Compatible DAQ devices
several vendors in one system
Adoption lifecycle
The adoption lifecycle
Prove it on one bounded system before it becomes your standard delivery pattern.
Pilot one mixed-vendor rig
Pick a real system with at least two vendors. Verify discovery, configuration, streaming and the shared time base across all of it.
Standardise the pattern
Turn the pilot into your commissioning approach with capability checks, configuration capture and a repeatable handover.
Specify for compatibility
Feed the capabilities each product has shown back into procurement so the next system starts from compatible products.
Protocol integrations
Protocol integrations and capability mapping
Some products reach openDAQ through a shared protocol integration rather than a vendor-written module. For an integrator the practical question is always what capability a given product exposes.
- A supported protocol and profile can make a product compatible through an existing shared mapping
- Protocol integrations bring products on other buses into the same model without per-project adapters
- Certification levels tell you what to expect before the equipment reaches site
Protocol-based compatibility depends on the specific protocol, profile and capability a product implements. Verify it per product during specification. Never assume a named protocol means full compatibility.
Named examples
Products you can build a system from
A mixed-vendor rig assembled from these needs no adapters written by you.
The full inventory, with verified capabilities and status, is on the community page
Resources
Where to look next
Everything here is public and needs no account, membership or sales conversation.
System integrators FAQ
The questions this decision usually turns on
How do we learn this and reduce risk on a live project?
What if only some products in the system are compatible?
How do we handle timing across vendors?
Does this create a dependency on openDAQ?
Next step
Bring us a system
Describe a mixed-vendor rig you are specifying or maintaining including the instruments, the software and the timing requirement. We will tell you which parts assemble today and which still need integration.