---
title: Measurements
slug: concepts/measurements
docTags: 11HRbizM9olUCcNKOmSMd
createdAt: 2025-07-17T09:18:42.455Z
---

## What is a Measurement?

A **measurement** represents a specific piece of data collected from your equipment or process (e.g. a temperature, speed, pressure, or production count) and stored in Factry Historian.

Think of a measurement as a named *stream of values over time*.

## Why does it matter?

Measurements are the **main data input** in the Historian. They allow you to track, visualize, and analyze your process in a meaningful way.

Every chart you see or calculation you make starts with one or more measurements.

## How does it fit in the system?

Measurements are configured on [Collectors](docId\:wp81bFTWmpUK-gFimCj6U). The collectors will retrieve that data from the data source and send it to the Historian.

Each measurement has:

- A name (e.g., Line1\_Temperature)
- A datatype (e.g. number, boolean, string)
- A destination database (see [Time-series databases](docId\:h4jS6GCABOg53kbawGyUa))
- A configuration specific to the collector's data source, for example:
  - A NodeID in the case of OPC-UA
  - A JSONPath in the case of MQTT with JSON payload

And can optionally have:

- A description
- Engineering specifications (e.g. Units of Measure, HI/LO boundaries, Min/Max scaling)
- [Tags & Labels](docId\:Zb70hNsdFNj3sJ42mYjXI) 

Here’s the flow:

:::BlockQuote
Machines → Collector → **Historian (as measurements)** → Visualizations / Reports
:::

Measurements can also feed into:

- [Calculations](docId\:OpIoDkGNNgYjeDX6zkg_D) (e.g., to average temperature over an hour)
- [Events](docId:0Ith2zLcAIs5YYwhSdTjE) (e.g., if RPM > threshold, trigger the start of a batch)

## Example

On a reactor, you might collect these measurements:

- Reactor1\_FillLevel: the liquid level in a reactor.
- Reactor1\_Speed: the RPM of the agitator.
- Reactor1\_Temperature: the temperature of the reactor medium.

Each is a separate measurement tracked over time, and will have:

- Measurement name
- A value (e.g. 72°C)
- A timestamp (e.g. 2025-07-17 14:35:03)
- A quality tag (e.g. Good, Bad)

## When you use it

You interact with measurements when:

- Naming and mapping data to collect from your equipment.
- Viewing real-time or historical trends in dashboards.
- Configuring events or calculations that use measurements.

Usually, measurements are defined during system setup and referenced throughout the system later. When new data sources are added, or new data is needed to feed a particular use case, new measurements are added.

## Common misconceptions

- A measurement is not a single data point, it’s a **time series** (a sequence of values over time).
- You don’t need to create measurements manually one by one. They are often bulk imported at system setup or afterwards, and can be created automatically when data arrives in the case of MQTT Sparkplug B, but you should still validate their naming and units.
- A measurement is not tied permanently to one device. You could remap it if needed, though with care to preserve history.

## Best practices

- Use clear, consistent names that reflect what the signal actually represents (e.g., Line\_Motor\_Temperature instead of Temp1).
- Document units of measure explicitly.
- Validate the data and the signal quality when commissioning. Don’t assume the device is sending good data.

## More information

- [Naming conventions and best practices](docId\:ElxtJ0BPaOcCpUhK9MSzg) 
- [Creating a measurement](docId\:u5-07YlMs2jiX9Kz-m-lB) 
- [Importing measurements in bulk](docId\:G5wek8Z-fIPXAU2YmzIRZ)