OPC Router lets you design data flows between OT and IT systems visually with drag and drop: PLCs, OPC UA servers, SQL and NoSQL databases, SAP, MQTT, REST and more. Being visual makes a flow easy to build; it does not make it well designed. A few principles keep flows understandable, safe and easy to maintain months later.
Give every flow one purpose, one trigger and a defined error behaviour. Build small, single-purpose flows rather than large ones that do everything, and document what each one does.
The structure of a flow
- Trigger: what starts the flow? Time (periodic), value change, condition (when a threshold is crossed) or an external event.
- Read the source: an OPC UA tag, a PLC variable, an SQL query, SAP data, a file.
- Transform: data type, unit, scaling, mapping, validation, merging.
- Write the target: a record into SQL, a publish to MQTT, a transfer to MES/ERP or a write to a PLC.
- Log and error path: write the result to a log; plan retries and alerts for failure.
Choosing the trigger
| Trigger | Suitable scenario | Watch out for |
|---|---|---|
| Periodic (time) | Regular logging, measurement journal | Triggering needlessly often strains the database and network |
| Value change | Production order, state, batch end | Add a delay or hysteresis against chattering signals |
| Condition / threshold | Alerts, event logging, alarm notification | Keep state so the same event is not triggered repeatedly |
| External event | An order from the ERP, a REST call | Validate incoming data; add protection against repeated requests |
Design principles
1. Small, single-purpose flows
Instead of “read tank level, write to SQL, raise an alert, notify MES, save to a file”, split each job into its own flow. Finding faults, changing and reusing become easier. Flow names should state the purpose: Line2_Production_SQL_Record.
2. Make transformation explicit
Keep type conversions, unit conversions and mapping tables visible; hidden assumptions are the most common source of errors. Do not drop quality and timestamp in a transformation (data quality and timestamps).
3. Define error behaviour up front
- What happens if the target database is unreachable? Is data buffered and retried, or dropped? (buffering)
- A retry must not produce duplicate records; add an id and a timestamp to records.
- Who gets the persistent-failure alert? A flow stopping silently is the most expensive fault.
4. Write in batches
Instead of writing every value to the database separately, writing records collected over a sensible interval in one transaction improves both performance and resilience (moving PLC data into SQL).
5. Extra care in the write direction
OPC Router works in both directions, which means you can write a production order or recipe to a PLC. Design PLC write flows with a handshake (ready flag, acknowledgement, read-back); restrict write permission and log every write (recipe transfer).
Testing and commissioning
- Try first with test sources (simulated values) and a test database.
- Test edge cases: empty values, bad quality, very large numbers, connection loss, repeated triggering.
- Measure the flow duration under load before going to production.
- Keep a backup of the flow configuration and a change log, so who changed what and when is traceable.
Using it together with Kepware Server
In a typical architecture Kepware Server collects data from field devices and serves it over OPC UA; OPC Router distributes this data to enterprise systems and carries orders from there to the field. Keeping the acquisition and integration layers separate lets each be changed and backed up independently (the right data collection path).
Frequently asked questions
Do I need to write code in OPC Router?
Flows are built visually with drag and drop; no programming knowledge is required. Complex transformations and expressions still call for logical thinking and testing discipline.
How many steps should a flow have?
There is no fixed number; the measure is that a flow has a single purpose. If it does several independent jobs, split it.
How do I know if a flow stops silently?
Add logging and “heartbeat” monitoring: raise an alert if the flow has not run for a set time.
