How it works
The architecture
The Core is the model every participant shares. Modules are how real devices, supported protocols and reusable processing plug into it and the same Core runs in the device and in the application.
Application · client
Your application
C++ · Python · C
openDAQ instance
openDAQ Core
devices · signals · properties · time
plus
Protocol integrations as client
connect out and mirror the remote tree
Function blocks
scaling · filters · FFT
Every device it connects to appears inside it as if local.
daq.nd://daq.opcua://daq.lt://
Device · server
A compatible device
instrument · standalone device
openDAQ instance
openDAQ Core
devices · signals · properties · time
plus
Device module
describes the local hardware as the root
Protocol integrations as server
native · OPC UA · LT · mDNS
Runs on the device itself or on a PC beside it.
A device module abstracts the local system the openDAQ instance is running on (a SIRIUS X, a FusionLN, a PC) and presents it in the openDAQ model as the root of the tree. It is the piece a device vendor writes. It does not connect out to anything. It describes what is here.
A protocol integration works in both directions. Facing outward it connects to something external over a protocol such as OPC UA, MQTT or ASAM CMP and brings it in as a device. Facing inward it exposes the openDAQ model through a protocol as a server. In either case the standard is carried through rather than replaced.
Protocol-based compatibility depends on the specific protocol, profile and capability a product implements. It has to be identified and verified per product.
A function block forms no connection at all. It performs a function inside the system such as processing, data generation, a data sink or configuring a subsystem by taking signals in and publishing signals out. Scaling, filtering, statistics and FFT are reusable and indifferent to which vendor made the device underneath. A function block can run on the device itself or in the application that reads it.
The three are easy to tell apart by one question: does it connect to anything? A device module describes what is here. A protocol integration connects out or serves. A function block does neither.
What it actually does
Every compatible product exposes these three through the same model and that is what lets one application work against many vendors' hardware.
openDAQ discovers compatible devices over mDNS on IPv4 and IPv6 so that an application can list what is reachable instead of asking an operator for IP addresses. Discovery also reports which connection and streaming capabilities each device offers.
import opendaq as daq
# list every compatible device on the network
instance = daq.Instance()
for info in instance.available_devices:
print(info.name, info.connection_string)Protocol integrations
A protocol integration maps a supported protocol and profile into the same common model. Where a product already speaks one of them that shared mapping can carry it into the ecosystem without a product-specific device module.
Product implements a protocol
e.g. OPC UA or ASAM CMP
Shared protocol integration
maps protocol → openDAQ model
Common device and signal model
same structure every client reads
Function blocks
Function blocks take signals in, calculate or analyse and publish signals out. Chain them into a processing pipeline that works the same regardless of which vendor produced the device underneath. They run wherever openDAQ runs, on the device itself or in the application that reads it.
Input signals
from any compatible device
Scaling
function block
FFT
function block
Output signals
published back into the model
Why one shared model
Without it every measurement software vendor builds and maintains its own adapter layer for the same devices.
Today: one adapter layer per vendor
OPC UA device
any vendor
DAQ device
any vendor
MQTT device
any vendor
Software A
own adapters, own drivers
Software B
own adapters, own drivers
With openDAQ: one shared layer
OPC UA device
any vendor
DAQ device
any vendor
MQTT device
any vendor
openDAQ
the adapter, once
Software A
integrates the model
Software B
integrates the model
How to validate
Start with a free conversation about your use case.
Bring a device, an application or a mixed-vendor system. We review the use case together and state whether openDAQ fits it and what the first bounded step would be.
A bounded prototype against your real product exposes enough device structure to establish discovery and basic streaming. It then provides a measure of what a full implementation would take.
Hands-on sessions for the engineers who will do the work. They are shaped around your architecture rather than a generic curriculum.
Every service is quoted per offer and several can be combined into one bundle with one scope and one price. A paid proof-of-concept fee may be credited toward a later engagement where the offer states this.
No account, membership or sales conversation is required.
Built for a product lifecycle
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.
Next step
A device, an application, a mixed-vendor system or a question. One contact route handles technical evaluation, partnership, membership and certification. You do not have to work out which department you need.