Glossary

DAQ

An acronym for Data Acquisition.

Component

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

Folder

An element that Components use to organize the children Components.

Device

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.

  • Physical device used for measuring data and is used to represent data acquisition hardware in openDAQ™.

  • Client device used to connect to another device, adding them below itself in the device hierarchy. It forms a parent-child relationship between itself and the connected-to devices.

  • Function Block device that defines data processing entities called Function Blocks. These can generate, process and output data as Signals. Here device acts as a parent of zero-or-more Function Blocks, and allows for their creation / removal / configuration.

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

Domain

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.

Signal

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.

Sample

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

Data Packet

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 Packet

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.

Data Descriptor

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.

Data Rule

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.

  • If the Data rule is explicit, samples are found as part of the data buffer.

  • If the Data rule is linear, or constant, the buffer is null, and each sample is calculated with a given packet offset (the packet offset is available in every Data Packet when required for the rule calculation):

    • Linear rule: Sample value = Packet offset + Index * Delta + Start; Where Index is the index of the sample in a packet. Delta and Start are given by the Data rule.

    • Constant rule: Sample value = Constant; Where Constant is given by the Data rule.

Post-scaling

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:

Sample value = Raw value * Delta + Offset

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.

Dimension

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.

Unit

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.

Tick resolution and Origin

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:

  • Origin = "1970-01-01T00:00:00Z"

  • Resolution = 1 / 1000000

  • Unit = "s" (seconds)

  • Sample value in ticks = 1676464831000000

We calculate the relative timestamp in seconds as Value * Resolution1676464831000000 * (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.

Function Block

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:

  • Statistics calculates statistics of its inputs, outputting averaged and rms signals

  • Signal Generator outputs simulated sine waves

  • File Writer writes input signal data into text files

Function Blocks
Figure 1. Function blocks with different combinations of input ports and output signals

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.

Channel

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.

Input Port

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.

Connection

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.

Reader

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:

  • Packet reader reads one-or-more packets at a time

  • Stream reader reads data as a stream of values, merging data packets into a continuous data buffer.

  • Tail reader reads the last n values output by the signal.

  • Block reader reads the data in predefined block size and can’t read less than a full block.

  • Multi reader reads aligned data from multiple signals.

Property Object

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.

Property

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:

  • Name: The name of the property.The Property is linked to a value via the name field.

  • Visible: If false, the property is not visible from outside the object.

  • Read-only: If true, the property value can’t be modified.

Property Value

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.

Context

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.

Scheduler

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

Logger

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.

Instance

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.

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.

Module

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:

  • opcua_client_module,native_stream_cl_module and ws_stream_cl_module which allow for connecting to Devices.

  • opcua_server_module which allows for setting up a Server that advertises Device structure.

  • native_stream_srv_module and ws_stream_srv_module which allow for setting up Servers that advertise Device Signals and stream Device data.

Device discovery

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 Streaming 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-ws._tcp.local. service, with a TXT record entry of caps=WS if device is Websocket-streaming-supported.

OPC Foundation

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-UA

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.

openDAQ™ OPC UA standard

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.

OPC-UA Server Module

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.

OPC-UA Client Module

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 Streaming 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.

Websocket Streaming Server Module

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

Websocket Streaming Client Module

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

The openDAQ™ Websocket Streaming Client Module enables its own web-socket streaming 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.

openDAQ™ Websocket streaming protocol

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.

Native Streaming Server Module

Allows for the creation of a native streaming server on an Instance. It publishes Device Signals and streams Device data.

Native Streaming Client Module

Allows for connecting to Devices running a native streaming server.

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

The openDAQ™ Native 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.

openDAQ™ Native streaming protocol

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