What's New in 5.7

Version 5.7 moves logic into the flow: conditions, reusable functions, and error handling are transfer objects; variables themselves form metrics; and certificates can be obtained centrally via an OPC UA Global Discovery Server. This page describes a typical use case for each new feature, along with the configuration steps, prerequisites, and reference pages. At the end, you’ll find what changes for existing projects .

New Feature	What It’s For
Condition (IF)	Execute parts of a flow only under a specific condition
Function (FX)	Define a process once and call it from multiple flows
Error Handling (Try/Catch)	Catch errors, retry calls, report exceptions
Change Gate	Execute downstream steps only when a relevant change occurs
Variables	Organize variables into folders, protect access data, create metrics, Dynamically access variables
DB Log Table	Write to a table whose structure the OPC Router creates and synchronizes itself
Certificates via OPC UA GDS	Obtain certificates centrally and renew them automatically
Start mode of Plug-in instances	Shut down unused instances or start them only when needed
Automatic logout	End sessions after inactivity or upon reaching the maximum duration

Condition (IF)

Use Case: If a temperature exceeds the threshold value, a message should be sent to the MES; all other values are simply written to the database.

Here’s how to configure it:

1. Drag the “Condition (IF)” transfer object from the tool palette into the flow.
2. In the “Inputs” tab, create an input named “Temperatur” and establish a connection between it and the read value. Enter “Temperatur > 80” as the condition and verify the expression using “Check”.”
3. Use “Create THEN” at the diagram node to create the THEN branch and configure the message to the MES within it. Use “Create ELSE” to create the ELSE branch with the write operation to the database. Declare values needed by both branches in the “Inputs” tab; results that the flow should reuse in the “Outputs” tab.
4. Publish the flow. In the object’s transfer details, you can see the condition result for each run, as well as the branch that was executed and the one that was skipped.

Prerequisites and Limitations:

• The THEN branch is required; the ELSE branch is optional. If there is no ELSE branch, the default values of the outputs apply when the condition is false.
• The condition follows the syntax of the calculator transfer object. There is no ELSE-IF; use nested conditions to implement multi-level decisions.
• Each branch call is limited to 30 seconds—just like any sub-flow call; see Time Limit for Sub-Flows. Changes to a branch take effect only after the flow is published.

Reference: Condition (IF) transfer object · Subflows · Publishing and Status

Function (FX)

Use Case: 30 systems provide data via different flows; the formatting of the values is the same everywhere. If the formatting changes, it should be updated in only one place.

Here’s how to configure it:

1. In the template interface (“Templates & FBs”), create a function using “New Function.” In the dialog, declare the contract: the inputs (e.g., Rohwert) and outputs (e.g., Wert) with their data types.
2. In the function’s Designer, configure the data processing between the scope input and scope return—using the same transfer objects as in a flow.
3. Drag the “Function (FX)” transfer object into each of the 30 flows and select the function. The contract’s inputs and outputs appear as items on the object and are wired as usual.
4. Publish the flows.

Modify: Edit the function in the template interface and republish the calling flows. The publish tree marks the affected flows as changed and selects them for publishing; flows that have not been republished continue to run with the previous version. If you change the contract (inputs or outputs), open and update the calling locations as well so that their items are adjusted accordingly.

Distinction from Templates: If entire flows are identical except for individual values, use templates and instances. Functions are suitable for an identical sub-process in otherwise different flows. Both can be combined: A template can also call a function.

Prerequisites and Limitations:

• Functions may call other functions. Circular references are rejected; the call depth is limited (default value 16).
• At most one call may run simultaneously per call site; the time limit for subroutines applies for its duration.
• When copying a call site to another project via the clipboard, the function is not copied along with it—use the file export feature instead.

Reference: Function Blocks · Publishing and Status · Working with Templates

Error Handling (Try/Catch)

Use Case: A job record cannot be written to the ERP system. Instead of the flow terminating, the OPC Router should retry the write operation and only notify the shift supervisor via email after a final failure—including the error message in the text.

Here’s how to configure it:

1. Drag the “Error Handling (Try/Catch)” transfer object into the flow and, in the “Inputs” tab, declare the job values required by both branches.
2. Use “Create TRY” on the diagram node to create the TRY branch and configure the write operation to the ERP system within it.
3. Enable “Automatically retry failed TRY calls” and set “Maximum retries” and “Wait time between attempts.” Leave “CATCH execution” set to “Only on final failure.”
4. Use “Create CATCH” to create the CATCH branch and map a transfer object within it. Establish a connection between the “CatchError” output of the scope input and the message text—and, if desired, also between “CatchFailedStep” (step number of the failed object) and “CatchAttempt” (the attempt number).
5. Publish the flow. The status output Recovered of the transfer object indicates to the flow that an error has been handled; in the transfer details, you can view each attempt individually.

Prerequisites and Limitations:

• Repetition is disabled by default and re-executes the entire TRY branch. It is only suitable for flows that may be executed multiple times. When writing to an ERP system, check whether a duplicate record could be created on the second attempt—for example, by having the TRY branch perform a query to determine whether the order already exists before writing.
• Without a CATCH branch, a final failure is not reported as an error; the default values of the outputs apply.
• An error in the CATCH branch causes the transfer to fail.
• During the attempts and waiting periods, the flow transfer is occupied; the subprocess time limit applies to the branch call.
• For email notification, you need an email connection via the email plug-in.

Reference: Error Handling (Try/Catch) Transfer Object · Sub-processes

Change Gate

Use Case: A counter value is read every second. Only a value that has changed by at least 5 from the last value written—but no more than once every 10 minutes—should be sent to the database, MQTT, REST, or a file.

Here’s how to configure it:

1. Drag the “Change Gate” transfer object into the flow. In the “Threshold Inputs” tab, create an input for the counter value, select the “Absolute Threshold” change mode, and enter 5 as the threshold value.
2. In the “Time” section, enable the heartbeat and set it to 10 minutes.
3. Use “Create Subflow” to create the subflow and configure it to write to the database. The monitored values are available in the subflow at the Scope input.
4. Publish the flow. If the gate remains closed, only the subflow is skipped; the transfer completes successfully.

Prerequisites and Limitations:

• The threshold modes require numeric values.
• The comparison basis is not permanently saved. After restarting the runtime, the comparison starts over; with “Skip first cycle,” the gate then opens during the first cycle.
• When the heartbeat is active, the target also receives unchanged values at the specified interval.
• The time limit for subprocesses applies to the call of the subflow.

Reference: Change-Gate transfer object

{#variablen} Variables

folder

Use Case: A project has several hundred variables; they should be organized by systems and topics.

Here’s how to set it up: In the Variables plug-in, create folders and subfolders via “New folder” and move variables using drag-and-drop. When creating a variable, select the folder in the “Folder” field. The name filter searches the entire tree.

Limitations: Variables from older projects whose names already contain / will remain flat variables after the update until you assign them a folder in the Edit dialog.

Credentials as Secrets

Use Case: An API key is required for multiple REST calls and should not be visible in the user interface or in the status.

Here’s how to set it up: Create a variable of type “Secret String” and set its value using the password dialog. Use the variable as the source for the HTTP header of the REST transfer object. The value is stored in encrypted form, displayed as masked text everywhere, and used in plain text only at the transfer destination.

Limitations: Secrets cannot be persisted or aggregated; the value serves as the initial value for the configuration.

Metrics over a time window (aggregation)

Use Case: A system’s consumption value is recorded in a variable every second. Only the average value for the time window—rather than 900 individual values—should be saved to the database every 15 minutes.

Here’s how to configure it:

1. Create a global variable named “Verbrauch” with a numeric data type and enable “Storage.”
2. In the Edit dialog, enable “Aggregation,” set the “Window duration” to “15m,” and under “Key Figures,” select, for example, “Average,” “Min,” and “Max.”
3. Write the measured value to Verbrauch using the variable transfer object as before. The metrics appear as separate variables—Verbrauch.Average, Verbrauch.Min, and Verbrauch.Max—below the source and are updated at the end of each time window.
4. Create a second flow with a variable trigger on Verbrauch.Average that writes the value to the database. The trigger fires exactly when a new time window has ended.
5. Deploy the configuration to production and restart the runtime.

Prerequisites and Limitations:

• Aggregation is only possible for global variables with persistence; it is not available for secrets. For non-numeric types, only Count is available.
• The time windows are based on a fixed grid of Coordinated Universal Time (UTC). A time window is closed with the first write operation after its end; a window without a write operation does not return a new value, and the metric variable retains the last window value.
• A time trigger that reads the metric variable cyclically is not aligned with the window grid and may still read the previous window. Use the variable trigger.
• Changes to the aggregation configuration take effect after going live with the runtime restart.

Reading and Writing Variables Dynamically

Use Case: The variable name is generated at runtime, e.g., from a system ID.

How to configure this: Use the transfer objects “Variables – Dynamic Read” or “Variables – Dynamic Write” and pass the variable name via the input pin. In templates, you can instead specify a path with placeholders in the variable transfer object and the variable trigger, e.g., {Anlage}/Temperatur.

Limitations: A new variable created dynamically initially exists only at runtime; to include it in the configuration, use “Include in Configuration.”

Reference: Variables Plug-in · Variables – Dynamic Reading · Variables – Dynamic Writing · Variables Triggers

DB Log Table

Use Case: A new series of measured values is to be logged in a database table that does not yet exist.

Here’s how to configure it:

1. Drag the “DB Log Table” transfer object from the “Database” tool group into the flow.
2. On the “Log Table” tab, select the data source, enter the table name, and define the columns with their name, data type, required field status, and default value. Mark the column as the primary key that should be used to update an existing record rather than insert a new one.
3. On the “Options/Behavior” tab, specify what happens in the case of differing, extra, or missing columns.
4. Establish connections between the column inputs and publish the flow. During the first transfer, the OPC Router creates the table.

Prerequisites and Limitations:

• The database user must have the right to create tables and—for “Correct”—to modify them.
• “Correct” deletes mismatched or redundant columns along with their data.
• Available for Microsoft SQL Server, Oracle, SAP HANA, MySQL, PostgreSQL, and MS Access connections; for SQLite, ODBC, and OLE DB, the OPC Router creates the table and adds missing columns, but does not modify or remove existing columns.

Reference: DB Log Table transfer object

Certificates via OPC UA GDS

Use Case: 40 installations across multiple plants communicate via OPC UA. The certificates are to be issued, renewed, and revoked centrally by IT without having to manage each installation individually.

Here’s how to configure it:

1. Under Certificates – Certificates via OPC UA GDS, create a new GDS application: GDS server URL, login credentials, and client certificate. Verify the information at “Check connection”.
2. In the Application tab, click “Register” and then “Request Certificate.” If necessary, wait for approval from the GDS administrator.
3. In the plug-in connections that are supposed to trust the GDS, set “Accepted Certificates” to “GDS” and select the certificate issued by the GDS—you can identify it in the drop-down lists by the name of the GDS application.
4. Put the configuration into production.
5. For additional installations, export the configuration and import it there. Use the placeholder ${hostname} in the Application URI and Application Name fields so that each installation is registered with the GDS under its own identifier.

Prerequisites and Limitations:

• An Enterprise license is required for each installation, as well as a Global Discovery Server within the company.
• The OPC Router updates revoked and renewed certificates during its next refresh (default every 5 minutes; adjustable from 1 minute to 24 hours). Existing connections will use these certificates starting with the next connection establishment.
• The GDS determines when a certificate is renewed.
• If the GDS is unavailable, the OPC Router continues to operate using the most recently retrieved certificates.
• You can continue to manage the HTTPS certificate for the web interface and any certificates you have imported yourself in the Certificate Management .

Reference: Certificate Management via OPC UA GDS

Startup Mode of Plug-in Instances

Use Case: A system is down for several weeks; its connection should not generate any connection attempts during this time. A test connection should only run as long as a flow is actually using it.

Here’s how to configure this: In the plug-in’s instance list, in the “Start mode” column, select “Disabled” for the idle system and “Auto” for the test connection. Deploy the configuration to production.

Behavior:

• “Auto” Starts the instance as long as an activated flow or template is using it, and stops it again when this is no longer the case.
• Flows that use a deactivated instance remain active; affected transfer objects display the status “Plug-in disabled”."
• Instances that are not started are not counted toward the Extension Suite license check.

Reference: Enabling and Disabling Plug-in Instances

Automatic logout

Use Case: Logged-in sessions on shared workstations should end after a period of inactivity, and no session should last longer than one workday.

To configure this: Set the global default values using the management service’s environment variables OR_WEB_SESSION_INACTIVITY_TIMEOUT_MINUTES and OR_WEB_SESSION_TIMEOUT_HOURS. In User Management, you can adjust both times on a per-user basis or disable them.

Prerequisites and Limitations: Both timeouts are disabled by default. Changed time settings take effect the next time the user logs in.

Reference: User Management – Automatic Logout

What’s Changing for Existing Projects

• Terminology: “Connection” is now called “Flow,” and “Connection Arrow” is called “Item Link.” This renaming applies to the user interface and the documentation; you can find the relevant section under Building Flows. The glossary explains the terms used in this version—including sub-flow, function (FX), contract, scope input, and scope return—
• .NET 10: The OPC Router runs on .NET 10. On systems with a CET-capable processor, Windows must be fully updated; otherwise, the services will not start—see System Requirements.
• MongoDB plug-in: The updated driver requires at least MongoDB 4.2—see MongoDB plug-in.
• Metrics: A maximum of 128 time series (attribute combinations) are tracked individually per metric; the metric collection aggregates any excess time series into a single overflow point. Systems with more attribute combinations per metric can raise the limit using the environment variable OR_METRICS_CARDINALITY_LIMIT (2000 corresponds to the previous behavior) – see Metrics Export.
• Automatic Logout: Both timeouts are disabled until you enable them.
• Variables: Names starting with / from older projects remain flat variables until a folder is assigned. Aggregation settings take effect after deployment, when the runtime restarts.
• Subflows: Changes to branches and functions take effect only after the calling flow is published again.
• Start Mode: Existing plug-in instances are set to the “Always On” start mode; their behavior does not change.