The first question plant IT asks, usually within the first five minutes, is whether the system touches their SCADA. The answer is yes, but only for observation. Food-processing SCADA carries control logic that external software should not alter. A bad PLC write could halt a line, open a valve at the wrong time, or send an incorrect command to a sorting diverter. After seeing vendor connections fail, plant IT is right to question any tool that says it connects to everything.
When we say Terrantic connects to SCADA, the important qualification follows: it reads only. It never writes. This article explains the implementation, its practical behavior, and the security issues that deserve attention.
What read-only means with OPC-UA
OPC-UA, or Open Platform Communications Unified Architecture, is widely supported for industrial data access in current food-processing plants. It lets outside systems read controller data without opening a path for write operations.
An OPC-UA server operates within or beside SCADA and presents a tag namespace. Examples include conveyor speed, scale weight, temperature output, sorter rejects, and cold-room ambient conditions. Each tag carries an address, type, and access level. SCADA configuration at the plant determines that access level, not the client connecting to it.
We configure the Terrantic edge agent to subscribe only to tag addresses the plant has marked readable. It connects as a read-only OPC-UA client. Because the server grants no write permission, the connection exposes no write path and cannot command a PLC. The plant chooses the available tags and permissions. Even if our software attempted a write, the server would refuse it.
Plant IT can confirm this directly in the OPC-UA server configuration, without relying on our assurance. The plant side owns the access control. That differs materially from an integration where safety depends on an outside vendor's code behaving properly. With OPC-UA configured correctly, infrastructure enforces the limit rather than a software promise.
Yield monitoring tag sets
A SCADA contains more tags than yield monitoring needs. In most fresh-food operations, the useful subset is smaller than expected.
Our usual subscriptions cover conveyor speed on each line, generally from belt encoders in meters per minute; line-scale weights, including gross and net values, typically updating at 1 to 4 Hz; sorter classifications, including pack, trim, and reject counts per minute from each sorter head; cold-room temperature at intake and steady-state points; and throughput counters at pack-out stations.
At a facility with four processing lines, the set is typically 80 to 120 tags. A SCADA may oversee hundreds of control loops and thousands of tags, so our required subset remains small and bounded. During commissioning, we review the list with plant IT. Each subscription is documented and auditable through the OPC-UA server access log.
Using MQTT instead
Some plants, especially those that updated control infrastructure during the past five years, operate MQTT brokers beside or instead of traditional OPC-UA servers. MQTT, or Message Queuing Telemetry Transport, is a lightweight publish-subscribe protocol common in newer edge deployments, where sensors or controllers publish directly to a broker rather than a historian-style SCADA.
When MQTT is available, the yield-monitoring pattern stays similar. The Terrantic edge agent subscribes to named topics, the MQTT equivalent of OPC-UA tag addresses, and receives changes as they occur. MQTT governs access by topic, rather than by tag access level, but the result is still a read-only subscription to a defined data subset, with the plant broker controlling scope.
If a facility runs both OPC-UA and MQTT, we use the system plant IT prefers to operate. We have no technical preference. The decision generally reflects which platform the IT team knows best for maintenance and monitoring.
Plant IT concerns
Two concerns recur in these discussions. Both deserve a direct answer, not dismissal.
The first is scan-cycle impact. Plant IT may worry that subscribing to 80 to 120 tags increases SCADA polling and affects control. Monitoring subscriptions in OPC-UA use publication, not continuous polling. The server sends changes, or publishes on a defined interval, instead of being queried constantly. Our yield-monitoring interval is typically 1 to 2 seconds, far slower than the millisecond-level PLC scan cycles. These functions run on separate execution paths.
The other issue is network design. Most facilities use IT/OT, or information technology and operational technology, segmentation to isolate SCADA. The Terrantic edge agent runs within that OT network on a plant industrial PC or server. SCADA does not need an outbound internet route. The agent aggregates yield data locally, then sends it to the cloud dashboard through a separate path configured by the facility network team. SCADA itself does not connect to an external endpoint.
Our on-premises deployment
The edge agent is a small Linux service. It runs on an available industrial PC or plant server, typically with 4 GB RAM and a modern processor using Ubuntu LTS or a similar distribution. Some facilities place it in a separate process on an existing historian server. Others choose a dedicated industrial PC on the OT network.
The agent maintains the OPC-UA or MQTT link, performs local aggregation and pattern detection, and manages the outbound route to the Terrantic cloud dashboard. If internet service drops, it keeps running and queues data locally until the connection returns. During an outage, the dashboard displays cached state and local alerts continue operating.
Deployment usually takes two to three days. Day one connects OPC-UA or MQTT, confirms the tag subscription with plant IT, and checks the data flow. Day two establishes yield baselines from a day of normal production. By day three, the dashboard displays live line data with pattern detection active.
The boundary we maintain
We should be precise about the security claim. A read-only OPC-UA connection is not zero-risk, because no external connection would be the zero-risk case. Any link into a control network adds attack surface, including a read-only link. That limitation is real.
A credentialed read-only OPC-UA subscription, with the plant controlling the tag namespace, belongs to the same general risk category as other read-only industrial feeds already used routinely, including historian systems, OEE monitoring tools, and energy-management platforms. Such tools have operated in plants for years. The practical questions are whether scope is narrow and whether controls sit on the plant side of the connection.
We do not ask plant teams to accept our security claim on trust. We provide integration documentation, answer implementation questions, and support the facility's own assessment. Plant IT should apply its standard OT controls and decide from its evaluation. Our responsibility is to make the connection clear enough for that review, including the limits enforced by the server and network design.