Glossary

An acronym for Data Acquisition.

A name for DAQ elements that share some common functionality. An example of these components are Device, Function Block, Channel and Signal.

An element that Components use to organize the children Components.

An openDAQ™ device represents a container of Channels, Function Blocks, Signals, and other child devices. openDAQ™ Devices can be split into three categories, with each Device being part of one or more of them.

Each Device also has a Device Info object containing information about it, such as its name and manufacturer.

Domain is a reference to a point where a Sample was acquired. In most cases, this is time but can also be something else, for example, frequency, angle, revolution or distance.

A Signal is used to form connections between data producers and consumers (Devices, Channels, and Function Blocks). It carries data in the form of Packets and describes the form of the data with a Data Descriptor.

Signals can have a reference to another Signal that provides its domain data. The domain data is used to align the samples and determine the distance between them. Most often, openDAQ™ signals use the time domain. In that case, a signal carrying measurement data will have a time signal as its domain signal, which provides the timestamps of each measured value.

A discrete value of a signal at some domain point (usually time).

Data packets are used to forward data from a Signal through a Connection, and into an Input Port. They contain a pointer to a data buffer and a reference to a Data Descriptor, describing the format of the data. Data packets have a specialization called Value packets. Value packets, in addition to the aforementioned, contain a pointer to another Data packet containing domain (most often time) data samples.

If packet data is implicit (calculated), the buffer is null, and the value of each sample is calculated using the signal’s Data Rule, given a packet offset.Each Data packet with an implicit rule contains a Packet offset.

Event packets are used to signalize to listeners that an event happened. They’re passed through a Signal in the same way as Data Packets. They contain an event id, and a dictionary payload containing key-value pairs relevant to a specific event.

A common event in openDAQ™ is the Signal-descriptor-changed event, which notifies all listeners that the Signal's description has been changed.

Contains information about the Signal data format such as sample type. Each Signal has a data descriptor. When said descriptor is changed, each signal listener is notified of the change with an event packet.

Allows anyone receiving Signal data to interpret the Packet data buffers.

The Data Descriptor contains information required to interpret and read the value of a single sample in a Data Packet's buffer. It contains information about the sample type (int, double, byte,…​), whether the sample is a scalar, vector, or matrix, as well as other necessary information.

The data descriptor is immutable, and can only be replaced in whole - its fields can’t be altered individually once assigned to a signal.

In special cases when complex data structures are sent via the Signal, the Data descriptor can contain a list of Data descriptors as Struct fields. When this list is configured, the samples in a Data Packet of the Signal are composed of multiple types of data (each described by a Data Descriptor in the aforementioned list), aligned consecutively in the data buffer.

Part of the Data Descriptor. Defines whether the values contained in the Signal's Data Packets are present in the buffer, or calculated via a rule and packet offset. The Packet offset is contained in every packet with a non-explicit rule.

Part of the Data Descriptor. Defines a scaling rule which is applied to a Data Packet's samples when read. When present, the Data Packets contain raw, unscaled values in their buffers, and are scaled as defined by the Scaling rule when they’re first read.

openDAQ™ defines a Linear scaling rule, which scales samples as follows:

Where Delta and Offset are given by the Scaling rule.

Post-scaling is most often used to reduce bandwidth requirements by outputting data in a smaller data format, such as Int32, then scaling it on the client side into Double precision values.

Data Descriptors contain a list of Dimensions. The number of Dimensions defines the rank of the data. For example, if a Data Descriptor has no Dimensions, a sample is composed of a single value. If it has 1 Dimension, a sample is composed of an array of values. If it has 2, a sample is a matrix of values.

The Dimension itself contains information about its size. The definition is in row-major order, so e.g., 2 dimensions of size 10 and 20 would represent a matrix with 10 rows and 20 columns.

Additionally, it can assign custom labels to each Dimension, defining the row/column width. A vector with Dimension labels [0, 2, 4, 6, 8] specifies that each value in the vector is a distance of 2 units apart.

Describes a physical unit of measurement, as defined in Codes for Units of Measurement used in International Trade. openDAQ™ defines the ID, symbol, name, and quantity fields for each of its units.

The tick resolution and origin are most often used to scale domain data from ticks to a given physical unit. The Resolution defines a ratio multiplier, while the origin defines a starting point in the domain to which a domain sample value is added to obtain the absolute domain value. A tick represents an integer value that is available in domain Data Packets, representing an unscaled domain data value.

For example, when using the time domain, the Origin represents an epoch, most often represented as a string according to the ISO 8601 standard. Let’s consider an example with the UNIX epoch:

We calculate the relative timestamp in seconds as Value * Resolution → 1676464831000000 * (1 / 1000000) = 1676464831, yielding the timestamp in seconds.

Converting the result into the ISO 8601 standard, and adding it to the Origin, we obtain the following absolute time value: "2023-02-15T12:40:31Z", or 15th February 2023, 12h 40m 31s.

Data processing objects that are used to generate, process, and/or output data. They define zero-or-more Input Ports to which input Signals are connected. They process inputs or generate their own data, usually outputting it either to their output Signals, or some other sink such as a file.

Function blocks are themselves a Property Object. They contain a set of Properties and corresponding Property Values that can be adjusted to modify the behavior of the Function Block.

Examples of Function Blocks:

Some more complex Function Blocks might have Function Blocks nested within them, to provide a better representation of hierarchical Properties, Signals, and Ports. For example, a File Writer Function Block might have a nested Trigger Function Block that specifies trigger conditions on when Signal data should be written to a file.

Specialization of a Function Block that represents a channel on physical hardware. openDAQ™ physical Devices contain a list of channels. Examples might include channels representing Analog inputs / outputs and CAN buses.

A Signal can be connected to an input port forming a Connection between the two of them. Whenever a packet is sent by the Signal, it is added to a queue of packets (the Connection object) and can be read by the owner of the Input Port.

An Input Port can specify a callback method, which determines whether a Signal is compatible with the port. If it is not, the Signal can’t be connected.

Input Ports are most often used by Function Blocks to obtain input data to process and Readers which read data sent by Signals.

Represents a connection between a Signal and an Input Port. In openDAQ™, a Connection is an object holding a FIFO (first in, first out) queue of Packets. Any Packet sent by a Signal is added to the queues of all Connections formed with the Signal.

Used to read data sent by Signals. Readers connect to Signals and provide an easy way of reading signal data in openDAQ™.

openDAQ™ provides different types of readers that can be used depending on user requirements:

Property Objects act as containers of Properties and their corresponding values. Each Property-Value pair is joined by a string key that is unique within a Property Object - the Property's name. In this pairing, the Property provides meta information that restricts the value, defines its default value, and provides insight on how to interpret it.

In openDAQ™, Devices, Channels, and Function Blocks are Property Objects. They define a set of Properties with default values. Adjusting the values of said Properties allows users to configure their behavior.

A Property describes the metadata of a property that is part of a Property Object. It defines what value its corresponding Property Value can hold, as well as other characteristics.

Examples of Property metadata fields:

The value of a Property. It can be obtained from a Property Object, using its name as the getter parameter. Conversely, a Property Value can be modified on a Property Object in the same manner but using the setter function.

If the Property Value has not been explicitly configured, it will return the default value of the corresponding Property.

A Property Value can’t be set unless a corresponding Property is added to the Property Object.

The Context serves as an "environment" context and contains the Scheduler and Logger. It originates at the Instance, and is passed to the Root device, which forwards it to Components such as Function Blocks and Signals.

A thread-pool scheduler that supports scheduling execution of one-off functions as well as dependency graphs.

Provides the ability for disparate components to record information on events and their severity. This can be output on the console, written to a file or otherwise displayed to the user.

The Instance is the entry point object to every openDAQ™ application. On creation, it initializes a Module Manager that loads all available modules from a specified directory (and its subdirectories). By default, it creates a standard openDAQ™ Root device, which allows access to all loaded Module capabilities (adding Function Blocks, adding Devices, starting Servers).

The openDAQ™ Instance forwards all Device function calls to its Root Device.

The top-level Device in the openDAQ™ Device hierarchy. It is the Device that is directly accessed when calling Device functions on the Instance. When an Instance is constructed, it creates a default root device. That Device, when doing actions such as adding a Device, or enumerating available Devices, iterates through all loaded Modules and asks them whether they can add a given Device or what Function Blocks they have available.

When an Instance (device) hosts an OPC UA Server, any client connecting to it will see the Device's structure, starting with the Root Device at the top.

A Module is usually a dynamically loaded library that provides a set of Function Blocks, servers, and supported Device types. It can be asked to add a provided Function Block / server to an openDAQ™ application, and to connect to a Device.

Not all modules provide each of these. For example, openDAQ™ provides:

When enumerating available Devices, each Module is queried for what Devices it can connect to / create. This is done with the Module's provided discovery mechanism. The openDAQ™ OPC-UA Client Module, Native Client Module and Websocket Streaming Client Module use a mDNS query to discover all supported devices on the network. Those Devices are assumed to be running a mDNS discovery service, advertising the _opcua-tcp._tcp.local. service, with a TXT record entry of caps=TMS if device is openDAQ™ OPC UA-supported, a mDNS discovery service, advertising the _opendaq-streaming-native._tcp.local. service, with a TXT record entry of caps=OPENDAQ_NS if device is Native-streaming-supported. and a mDNS discovery service, advertising the _streaming-lt._tcp.local. service, with a TXT record entry of caps=WS if device is Websocket-streaming-supported.

The OPC Foundation (Open Platform Communications) is an industry consortium that creates and maintains standards for open connectivity of industrial automation devices and systems, such as industrial control systems and process control generally.

OPC Unified Architecture (OPC UA) is a cross-platform, open-source, IEC62541 standard for data exchange from sensors to cloud applications developed by the OPC Foundation.

A test-and-measurement standared that describes openDAQ devices based on the OPC UA for devices standard. It is a protocol that describes the structure of a Device. The openDAQ™ OPC-UA Client Module can connect to Devices that adhere to this protocol.

Allows for the creation of an OPC UA server on an openDAQ™ Instance. It publishes the structure of the Root device and all its descendants (other Devices and Function Blocks), and allows for changing the Property Values of all the structures from a remote client.

The structure is as of this moment locked to the state it is when the Server is created. If a new Function Block, Device, Channel, or other Component is added, the Server doesn’t yet react to that change.

Allows for connecting to openDAQ™ OPC UA-enabled devices running an OPC UA server. It reads the structure of the remote Device and mirrors it as a sub-device. Settings changed on the Device mirror are also changed on the actual Device itself.

The openDAQ™ OPC-UA Client Module also can use openDAQ™ Native Client Module and openDAQ™ Websocket Streaming Client Module to connect to the server component created by the corresponding Streaming Server Module. Doing so enables transferring Data Packets from server Signals into client Signals.

Allows for the creation of a web-socket streaming-lt server on an Instance. It publishes Device Signals and streams Device data.

Allows for connecting to Devices running a web-socket streaming-lt server.

The openDAQ™ Websocket Streaming Client Module enables its own web-socket streaming-lt client, which connects to the server component created by the openDAQ™ Websocket Streaming Server Module. Doing so reads server signals and transfers data packets from server signals into client signals.

The openDAQ™ Websocket Streaming Client Module allows to read the list of all signals of the remote Device and mirror these as a flat list as if owned by a "pseudo" local Device. This "Pseudo" Device does not mirror Channels or Function Blocks of the remote Devices, and does not provide a mechanism to change settings of the remote Device.

The data transfer protocol used by openDAQ™ to publish Device available Signals and send data from Devices running an openDAQ™ Websocket Streaming Server to an openDAQ™ Websocket Streaming Client.

Allows for the creation of native configuration and streaming servers on an openDAQ™ Instance.

The configuration server publishes the structure of the Root device and all its descendants (other Devices and Function Blocks), and allows for changing the Property Values of all the structures from a remote client. The structure also dynamically adjusts to accommodate broader modifications, such as the addition of new Function Blocks, Devices, Channels, or other Components.

The streaming server publishes Device Signals and streams Device data.

Allows for connecting to Devices running native configuration and streaming servers.

It reads the structure of the remote Device and mirrors it as a sub-device. Settings changed on the Device mirror are also changed on the actual Device itself.

The openDAQ™ Native Client Module enables its own native streaming client, which connects to the server streaming component created by the openDAQ™ Native Server Module. Doing so reads server signals and transfers data packets from server signals into client signals.

The openDAQ™ Native Client Module also allows to read the list of all signals of the remote Device and mirror these as a flat list as if owned by a "pseudo" local Device. The "Pseudo" Device does not mirror Channels or Function Blocks of the remote Devices, and does not provide a mechanism to change settings of the remote Device.

The data transfer protocol used by openDAQ™ to publish Device available Signals and send data from Devices running an openDAQ™ Native Server to an openDAQ™ Native Client.

It is a protocol that describes the structure of a Device. The openDAQ™ openDAQ™ Native Client can connect to Devices that adhere to this protocol.

The generalized transport layer mechanism for continuous and real-time receiving of data from a data acquisition Device.