“Use a Machine-Level Historian or a Server Software Historian?” That’s The Wrong Question to Ask

As a vendor who builds historians and edge gateways, I can tell you that question is fundamentally wrong and leads to useless debates. In fact, I’ve seen engineers argue over machine-level historians versus enterprise software historians until it deteriorates into a cage match that no one wins. 

Nobody ever wins, because the two aren’t competing—they’re doing different jobs. 

One captures the unfiltered truth at the machine the moment it happens. The other builds the shared, plant-wide story your business runs on. Pick by preference instead of by purpose, and you don’t just make a suboptimal choice, you buy yourself blind spots, dead-end troubleshooting, islands of orphaned data, and the most dangerous outcome of all: total confidence in records that are quietly full of holes. 

This article describes how to stop guessing and choose a historian that is best suited for the required task. Here are a few key points we will address:

1. Neither a machine-level historian nor a software historian is best. Pick the architecture based on the job function you need done.
2. Pick wrong and you get poor visibility, inadequate troubleshooting, islands of data and gaps in your data.
3. The selection criteria includes what data you need, how fast you need it, what happens on a network outage, who supports it, and what infrastructure currently exists.
4. There is a use case for implementing both a machine-level historian and a software historian.
5. A simple picking guide assists with the decision. 

What is a machine-level historian?

A machine-level historian is a machine-based device that is directly connected to the control system network to collect, store, and retrieve high-volume, event-triggered, and time-series data from industrial processes, sensors, and machine networks. 

A machine-level historian is directly connected to the Ethernet switch that forms the control system network and can easily collect data from devices on that control system network (Figure 1). It is typically a machine-hardened, DIN-rail computing device using a robust, fit-for-purpose operating system like Linux.

Machine-level historians directly access the internal data tables of many programmable controllers. Some can collect data from devices other than programmable logic controllers (PLCs). Historians that support I/O networks can collect data from EtherNet/IP or PROFINET I/O networks. Others can interrogate Modbus or Simple Network Management Protocol (SNMP) devices to retrieve pending link failures and device status.

Figure 1: A machine-level historian is directly connected to the control network of a machine through a network switch.

What are common uses for a machine-level historian?

Machine-level historians can be used in any industrial process but are most commonly used in:

• Diagnostic applications: A machine-level historian monitors specific tags in the PLC. When an event is triggered, it collects detailed machine data to provide data that a control engineer can use to solve a problem. In sequence of events (SOE) monitoring, this is useful for better understanding what triggered equipment shutdowns.
• Track and trace applications: A machine-level historian collects product data as part of a system to verify the location and historical journey of a product through a process. This is most often used to track medicine in pharmaceutical applications, food products for product recalls, and packages in logistic applications.
• Process audits: A machine-level historian collects data that documents the process used in a production process. For example, it collects temperatures in a curing process to prove that a part was baked and cooled for the correct amount of time.

What are the limitations of a machine-level historian?

Machine-level historians are limited by their scope of service. Where a software or enterprise historian is considered the one corporate version of the truth and can aggregate data from multiple machines, a machine-level historian contains only the time-series records (often at a higher fidelity) from a single production control system.

Machine-level historians are also limited by the storage space available in the device. Because they are embedded devices, the record data storage can be limited. However, with up to a terabyte drive per machine, you’re likely to have a repository that can span from cradle to grave for a machine.

Machine-level historians also don’t offer the kinds of data reporting capabilities found in software and enterprise historians. Dashboards, trend charting, and data reporting are often available but generally much less sophisticated than the powerful applications found in server-based historians. However, they do offer data connectivity that enables the use of external analytics tools.

How secure are machine-level historians?

The cybersecurity attributes of machine-level historians vary. Some older historians were not designed as cybersecure devices. Since the adoption of the ANSI/ISA-62443-4-1 standard for secure embedded devices, more historians have been developed with secure practices. These practices include secure browsers and encryption of their internal databases.

What is a software historian?

A software historian is a server-based software application that collects, stores, and retrieves high-volume, time-series data from industrial processes, sensors, and machines. Like machine-level historians, a software historian used in a control system application focuses on time-series data, but it can also ingest relational data from enterprise resource planning (ERP) and manufacturing execution system (MES) applications. 

Unlike a machine-level historian, it is designed to handle vast amounts of data from multiple sources. It also generally provides more extensive trending, charting, and reporting capabilities, enabling operators and engineers to analyze historical data to improve operational efficiency, perform predictive maintenance, and comply with auditing requirements. 

What are common uses for a software historian?

A software historian is used in the same types of applications as a machine-level historian. The difference is that the software historian can ingest time-series data from multiple machine sources and typically has more extensive charting, analysis, and storage capabilities.

What are the limitations of a software historian?

Server or networking issues can impede the collection of process data in a software historian. A failure, reboot, or delay by a network device between the data source and the software historian can obstruct data collection or cause the data to be missed altogether.

Software historians operate on Windows and Linux servers. These factory floor servers are information technology (IT) devices requiring regular service updates, patches, and other maintenance. These maintenance activities can interfere with data collection, especially if the maintenance activity is unscheduled. Software historians used for process audits can miss important records during maintenance outages.

Software historians are often located outside the production or process zone, so data may pass through multiple switches and routers before being recorded. This reduces the accuracy of the historian’s time stamps and can impede the accuracy and conclusions of analytic tools.

How secure are software historians?

A software historian is connected to more devices on the operations network and has a larger cyberattack footprint. Cybersecure operation is more critical to a software historian because it is more connected. 

Users are encouraged to verify that their software historian was developed using the ANSI/ISA-62443-4-1 standard.

When to use both a machine-level historian and a software historian?

When used together, the combination of a machine-level historian and a software historian provides a more complete picture of the machine than either used alone. The machine-level historian provides highly accurate, properly timestamped, and complete time-series records. The software historian both archives the records from the machine-level historian and combines them with relational records generated by ERP and MES systems to form a complete picture of machine operation. 

How to choose a historian for your architecture? 

Here are three questions to ask when deciding which historian to use:

1. If your question is, “How do I catch what really happened on this machine?” start with the machine-level historian. That is the stronger choice for local evidence, troubleshooting, traceability, and audit-grade capture close to the source.
2. If your question is, “How do I give the plant or the enterprise a shared, scalable history and reporting layer?” use a software historian. That is what server historians are built to do.
3. If your question is, “How do I avoid choosing between machine truth and enterprise visibility?” the strongest architecture is often both together. Capture locally first, then synchronize or archive upward. 

Table 1 describes best practices for choosing a machine-level historian, a software historian, or both.

Table 1: Decision factors used to choose between software and hardware historians.

FAQs

1.    Why do I need a historian in my control system?

A historian captures the high-volume, event-triggered, and time-series data your control system generates so you can use it later. That data drives three core jobs: machine diagnostics (catching what happened when a fault triggers), track and trace (verifying a product’s journey through a process), and process audits (proving a step ran to specification, like a curing cycle hitting the right temperature for the right time). Without a historian, that record simply doesn’t exist when you need it.

2.    What’s the difference between a machine-level historian and a software historian?

A machine-level historian is a hardened, DIN-rail device wired directly into the control network to capture data from one machine or cell with high fidelity. A software historian is a server-based application that aggregates time-series data from many machines and adds richer trending, analysis, and long-term storage. The machine-level device captures local truth; the software historian builds shared, plant-wide history.

3.    Which historian (machine-level or software) is better?

Neither, that’s the wrong question. They do different jobs. Choose based on what the data has to accomplish: catching exactly what happened at one machine points to a machine-level historian, while shared reporting and multi-asset visibility points to a software historian. In many high-value systems, the strongest architecture is both working together.

4.    Can I use both together?

Yes, and it’s often the best architecture. The machine-level historian captures accurate, properly timestamped, complete records at the source, then the software historian archives those records and combines them with relational data from ERP and MES systems. You get local depth and enterprise breadth—capture locally first, then synchronize or archive upward.

5.    What happens to my data during a network or server outage?

This is a key differentiator. A machine-level historian keeps capturing because it sits locally at the machine, independent of upstream servers and network paths. A software historian is more exposed; a failure, reboot, or unscheduled maintenance window between the source and the server can obstruct or lose data entirely, which is especially risky for process audits. This is why local capture matters when losing machine detail is unacceptable.

6.    What is the difference between a machine-level historian and an edge gateway?

The biggest distinction is retention. An edge gateway typically doesn’t store data; it collects and forwards it to external applications. A machine-level historian is built to retain the time-series record so you can retrieve it later for diagnostics, traceability, and audits.

7.    Are historians cybersecure?

It varies. Older machine-level historians weren’t always designed with security in mind, though newer ones increasingly follow the ANSI/ISA-62443-4-1 standard, including secure browsers and encrypted internal databases. Software historians benefit from mature, centralized IT controls but carry a larger cyberattack footprint because they’re more connected. For either type, verify that it was developed to the ANSI/ISA-62443-4-1 standard.

Conclusion

Stop asking which historian wins. Ask what job must be done and let the architecture follow.

• Use a machine-level historian when the cost of not knowing exactly what happened on one machine is high. 
• Use a software historian when the job is aggregation, reporting, long retention, and multi-asset visibility. 
• Use both when you need the machine to capture the truth first, and the server to archive, contextualize, and share it across the plant.

Get that right, and your data stops being blind spots and orphaned islands and becomes something you can trust when it counts.