OPC Classic™
Connect to OPC Classic™ servers using OIBus with the OIBus Agent.
- Industrial communication protocol by OPC Foundation
- Supports both HDA and DA mode
- Requires Windows-based OIBus Agent
- For OPC UA, see OPC UA connector
OIBus Agent must be installed on a Windows machine
OPC Classic vs OPC UA
| OPC Classic™ | OPC UA | |
|---|---|---|
| Standard | Three separate specs: DA (live values), HDA (historical data), AE (alarms & events) | Single unified standard: DA (live values) + HA (historical access) + alarms |
| Historical mode name | HDA — Historical Data Access | HA — Historical Access (OPC UA Part 11). Same concept, different name — see note below |
| Transport | COM/DCOM — Windows inter-process communication only | TCP/IP or HTTPS — works over any IP network |
| Platform | Windows only | Cross-platform: Windows, Linux, macOS, embedded |
| Security | Relies on Windows domain/DCOM security | Built-in: message signing, encryption, certificate-based auth |
| Introduced | 1996 | 2006 |
| OIBus requirement | Requires an OIBus Agent running on the Windows machine that hosts the OPC server | Connects directly from OIBus — no agent needed |
Users coming from an OPC Classic background often look for HDA in OPC UA and cannot find it.
OPC UA renames the equivalent feature HA (Historical Access, defined in OPC UA Part 11).
The concept is identical — querying a server for values recorded in the past — but the acronym
changed. In OIBus, this connector calls the mode HDA, and the OPC UA connector calls it HA.
Do not confuse OPC UA HA with OPC Classic HDA: they are separate protocols and are not
interoperable.
Choose OPC Classic when your infrastructure already runs OPC DA or OPC HDA servers that cannot be migrated. The COM/DCOM technology that OPC Classic relies on is Windows-only and does not travel over standard IP networks without DCOM tunnelling — hence the requirement for OIBus Agent to run directly on the Windows host.
Choose OPC UA for any new deployment. OPC UA is the current industry standard, supported on all platforms and with security built in. See the OPC UA connector for details.
Common OPC Classic Servers
| Server | Vendor | Modes | Notes |
|---|---|---|---|
| KEPServerEX | PTC (Kepware) | DA, HDA | Most widely deployed OPC gateway; supports hundreds of PLC, DCS and device types. Also exposes an OPC UA endpoint — see the OPC UA page |
| FactoryTalk Linx | Rockwell Automation | DA | Standard OPC DA server for Allen-Bradley / ControlLogix PLCs |
| SIMATIC NET PC Software | Siemens | DA | OPC DA access for S7-300 and S7-400 PLCs. S7-1500 and newer expose native OPC UA — use the OPC UA connector instead |
| Matrikon OPC | Honeywell | DA, HDA | Large catalogue of device-specific OPC servers, including a widely used free simulation server |
| PI Server | AVEVA (OSIsoft) | DA, HDA | Industry-leading process historian; also exposes an OPC UA interface |
| Proficy Historian | GE Digital | HDA | Common historian in manufacturing and utilities |
| InfoPlus.21 | AspenTech | DA, HDA | Widely used in oil & gas and chemical industries |
Specific Settings
| Setting | Description | Example Value |
|---|---|---|
| Remote agent URL | Agent endpoint (e.g., http://host:2224) | http://192.168.1.100:2224 |
| Retry interval | Time (ms) before connection retry | 10000 |
| Server URL | Address of OPC server (from agent machine) | localhost or IP address |
| Server name | OPC server name (ProgID) | Matrikon.OPC.Simulation |
| Mode | Data access mode (DA or HDA) | HDA |
Group Settings
Items are organised into groups. Each group defines a shared schedule and, for HDA mode, the default throttling parameters for all items it contains.
| Setting | Description | Example Value |
|---|---|---|
| Name | Unique label for the group within this connector. | Group A |
| Scan mode | Collection schedule applied to every item in the group. | Every 1 min |
Throttling Settings
Throttling controls how OIBus paces historical data requests. These settings appear on each group (for connectors that support groups) or on each item (for single-item connectors). Items in a group can override the group defaults by disabling the Sync with group toggle.
| Setting | Description | Example Value |
|---|---|---|
| Max read interval | Maximum duration of each sub-query in seconds. Larger time ranges are automatically split into chunks not exceeding this value. | 3600 |
| Read delay | Pause in milliseconds between consecutive sub-queries. Helps prevent server overload and manages rate limits. | 1000 |
| Start time offset | Milliseconds added to the start of the query window (@StartTime). A negative value moves the start earlier, to capture late-arriving data from the previous interval — this is the old "Overlap" behavior. A positive value moves the start later instead, skipping that much of the window. | -60000 |
| End time offset | Milliseconds added to the end of the query window (@EndTime). A negative value pulls the end in earlier — useful for eventually-consistent sources where the very latest rows aren't reliable yet. A positive value extends the window later. If the resulting end is not after the effective start, the query is skipped for this run. | 0 |
| Recovery strategy | Order in which OIBus catches up on a backlog of unqueried sub-intervals — e.g. after being stopped for a while, or on first run against a wide time range. From oldest to newest (default) processes the backlog chronologically. From newest to oldest queries the most recent sub-interval first, so up-to-date values become available immediately while older gaps are backfilled afterward. | From oldest to newest |
How Throttling Works
- Interval splitting — A 24-hour range with
Max read interval = 3600(1 hour) is split into 24 separate 1-hour sub-queries. - Read delay — A pause is inserted between sub-queries to manage server load.
- Start/End time offset — With
Start time offset = -60000(-1 minute), a query for[10:00–11:00]actually requests[9:59–11:00], ensuring no late-arriving data is missed.End time offsetshifts the other boundary the same way. - Recovery strategy — Only matters when there's more than one sub-interval to catch up on. With
From newest to oldest, the tracked instant only advances once every sub-interval in the backlog has been queried — this avoids skipping over not-yet-queried older intervals if OIBus restarts mid-catch-up.
Start/End time offset are applied once, to the start and end of the overall query window — not to the start of each individual sub-interval when a large range is split into chunks by Max read interval.
Recommended Configurations
| Scenario | Max read interval | Read delay | Start time offset |
|---|---|---|---|
| Stable network, small datasets | 3600 (1 hour) | 500 | 0 (none) |
| Unstable network | 1800 (30 min) | 2000 | 0 (none) |
| Large historical retrievals | 7200 (2 hours) | 1000 | 0 (none) |
| Real-time with occasional gaps | 900 (15 min) | 200 | -15000 (-15 sec) |
For the reasoning behind these numbers — sizing Max read interval against real data volumes, the Read delay / Max read interval trade-off on a large backlog, and worked examples of Start vs. End time offset (including the batched multi-item case where items don't all flush at once) — see Tuning South History Call Settings.
Each item can override the group throttling defaults by disabling the Sync with group toggle in the item edit form.
Item Settings
| Setting | Description | Example Value |
|---|---|---|
| Node ID | Path to data in OPC server namespace | Channel1.Device1.Tag1 |
| Aggregate | Data aggregation method (verify server support). See note below for full list. | Raw, Average, Minimum, … |
| Resampling | Resample aggregated values at requested interval (requires non-Raw aggregate) | None, 1 second, 1 hour, … |
- Aggregation Support: Not all servers support all aggregation methods
- Resampling: Only available when aggregate ≠
Raw - Recommended Settings: Use
Rawaggregation andNoneresampling for maximum compatibility - Server Capabilities: Verify supported features with your OPC server documentation
| Value | Description |
|---|---|
| Raw | All raw values in the interval |
| Interpolative | Interpolated value at the requested time |
| Total | Sum of all values in the interval |
| Average | Arithmetic mean |
| Time average | Time-weighted average |
| Count | Number of data points |
| STDEV | Standard deviation |
| Minimum actual time | Minimum value with its actual timestamp |
| Minimum | Minimum value in the interval |
| Maximum actual time | Maximum value with its actual timestamp |
| Maximum | Maximum value in the interval |
| Start | First value in the interval |
| End | Last value in the interval |
| Delta | Difference between first and last value |
| Reg slope | Linear regression slope |
| Reg const | Linear regression y-intercept |
| Reg dev | Linear regression deviation |
| Variance | Statistical variance |
| Range | Maximum minus minimum |
| Duration good | Duration of good-quality data |
| Duration bad | Duration of bad-quality data |
| Percent good | Percentage of good-quality samples |
| Percent bad | Percentage of bad-quality samples |
| Worst quality | Worst quality code in the interval |
| Annotations | Annotation events |
None · 1 second · 10 seconds · 30 seconds · 1 minute · 1 hour · 1 day
Configuration Examples
- Basic Configuration:
- Node ID:
Simulation Random.Int4 - Aggregate:
Raw - Resampling:
None
- Aggregated Values:
- Node ID:
Production.Line1.Temperature - Aggregate:
Average - Resampling:
1 minute
- High-Frequency Data:
- Node ID:
Process.Vessel.Pressure - Aggregate:
Minimum - Resampling:
1s