An Important Smart Factory Decision:
When to Use a Machine Level Historian
A machine level historian is the right choice when you need reliable, local time-series retention close to the PLCs to troubleshoot intermittent faults, support local traceability, or retain evidence for process audits even during network or server outages. Use it when the business value depends on data continuity and fast access at the machine or line, and when deploying a server-based enterprise historian is overkill or unrealistic.
What Are the Different Types of Data Historians?
Historians are not easily classified by feature lists. Instead, historians are most easily classified by the deployment model, licensing model and their location in the control hierarchy:
- Cloud Historians reside in the cloud, are far away from the control system, are managed by IT, are software deployed and require subscriptions.
- Enterprise Historians reside within the enterprise and can be outside the production system firewall. They are software-based, fully featured, complex, IT-managed and use subscription licensing.
- Software Historians reside within the production system firewall, are deployed on servers and VMs and are typically managed by IT or by manufacturing IT.
- Machine Level Historians reside in the control system, are hardware-deployed (typically in the control cabinet with a PLC), are less complex and are available as a one-time purchase.
How to Decide Which Historian You Need?
When deciding which type of historian you need, use a few variables: outage tolerance, required sample rate, retention period, number of tags and who owns support (controls vs IT), then map those to must-have features and cybersecurity boundaries.
| Requirement | Machine Level | Software | Enterprise | Cloud |
|---|---|---|---|---|
| Number Sites | Single | Single | Single | Multiple |
| Retention | Hours, Days, Weeks | Months | Years | Forever |
| Storage | Terabyte or less | Multiple Terabytes | Unlimited | Unlimited |
| Typical Sampling | 1 msec to 100 msec | 100 msec to 1 min | >1 minute | >1 minute |
| Tolerance to Outages | Absolutely No Loss of Data | Sporadic Outages Tolerable | Sporadic Outages Tolerable | Sporadic Outages Tolerable |
Use a machine level historian when:
-
Use a machine level historian when:
- Resilience through server reboots and network interruptions is critical
- It is critical to resolve machine faults quickly
- You need machine or cell-level traceability
- You do not want to deploy a server, VM
- IT resources are unavailable or not involved
- Budget is local to maintenance or engineering
- You want to avoid license costs and subscriptions
- Flat CSV files are too limited
- You need advanced triggering options
- Time-stamped values are critical to audit trails
What Are the Key Features of a Machine Level Historian?
Machine level historians have a range of capabilities, and no matter how simple or complex your application is, the following checklist can guide you through the selection process.
The most indispensable features of a Factory Floor Historian are:
Connectivity
A machine level historian must pull raw signals from the real sources, PLC tags, remote I/O and industrial network gear.
Data conditioning (normalize, scale, and standardize)
Controller data is often “machine native,” not “enterprise ready.” Units, ranges, data types and even naming conventions vary between lines and vendors. A usable historian should clean that up on ingest, creating consistent units, consistent types and consistent engineering scaling so downstream systems are not forced to guess.
Structure and context (data modeling)
Storing tags is not the same as making data usable. In a perfect world, the historian supports common industry models and lets you extend them. In the real world, the key question is simpler: can it represent your company’s hierarchy and naming rules, and can you load or map to the standard model for your organization?
Event-based capture (flexible triggering)
Not everything should be logged on a fixed interval. Good machine level historians can capture on time, on state changes, on end-of-cycle, on end-of-shift, on alarms, on quality events or when a process goes out of bounds. Most diagnostic and “why did it fail” questions show up after the fact. Triggers let you capture the data you need when it matters.
Export and exposure (transfer vs publish)
After capture, data must leave the box in a usable way. “Transfer” can mean exporting files (CSV, database extracts), writing to removable media where allowed, or pushing to a server share. “Publish” means exposing selected, structured data over common interfaces like MQTT (and Sparkplug where relevant), OPC UA or REST so other systems can subscribe, query, and act.
Security posture (fit the plant’s requirements)
Security is not one checkbox. Some sites need basic hardening and authentication. Others need network segmentation, auditability, a secure update process and alignment with policies tied to IEC 62443, CISA guidance or product security rules such as the EU CRA. The point is not to chase buzzwords. It’s to match the historian’s security capabilities to your plant’s risk and compliance reality.
Accurate timestamps (time sync at the source)
Time-series data is only valuable if time is trustworthy. Timestamps should be generated at the point of collection and aligned to a shared clock. NTP is common, PTP is used when precision matters, and some devices rely on a stable internal clock with periodic synchronization. Without consistent time, comparisons across machines and systems become suspect fast.
Machine Level Historian Architecture Example
Any process zone is a candidate for a machine level historian. The image below provides an example using the RTConnect A-B PLC Historian.
Process zones typically include a cell switch, a programmable controller, some direct I/O, some networked I/O and SNMP devices. Other networks should be considered, as BACnet and Modbus TCP networks can contain environmental and utility data important to the process.
In this architecture, database applications outside the zone extract time-series data from the historian for analysis or long-term storage. Enterprise applications access data models published by the machine level historian over MQTT or OPC UA to perform various application services.

When is a Machine Level Historian the Wrong Choice?
Machine level historians are purpose-built application databases that collect time series data in production control systems. They are not general-purpose relational databases. You typically do not use a machine level historian:
- To capture Automation Level 3 and Level 4 transactions
- To retain time-series data for years
- To do complex processing and data analysis
- When Connection issues and outages are tolerable
- When sampling rates are not critical
- When you need corporate-wide aggregation
- When you require advanced analytics dashboards across multiple plants
- If IT already runs a standardized historian stack
- If centralized cloud reporting is mandatory
- When you need deep MES integration
FAQs
A machine level historian is a local time-series database appliance placed near the control system to collect PLC tags with accurate timestamps and retain data through network or server outages.
An edge gateway is optimized to normalize and publish data to other systems. A historian is optimized to timestamp, buffer and retain time-series data for trending, investigation and reporting.
Start with tag count, sample rate and retention period. Then add headroom for buffering during outages and for higher-rate tags used in diagnostics. Determine the required storage for your application using our RTConnect A-B PLC Historian data storage comparison table.
Choose machine level when reliability and simplicity at the machine/line matter more than enterprise governance, and when deploying and maintaining a server-based platform is too heavy for the use case.
Place it inside the machine/line zone (or the site operations zone) with strict conduits. Minimize inbound access, control northbound publishing, and enforce least-privilege accounts and logging.
About the Author
John S. Rinaldi
Real Time Automation, Inc.
John Rinaldi is Chief Strategist and Director of WOW! for Real Time Automation (RTA) in Pewaukee WI. With a focus on simplicity, support, expert consulting and tailoring for specific customer applications, RTA is meeting customer needs in applications worldwide. John is not only a recognized expert in industrial networks and an automation strategist but a speaker, blogger, the author of more than 100 articles on industrial networking and six books including Industrial Ethernet, OPC UA: The Basics, Modbus, OPC UA – The Everyman’s Guide and ETHERNET/IP.
