> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/2-4-2/guides/migration/migrating-from-opc-router.md). # Migrating from OPC Router This guide shows you how to migrate an inray OPC Router project to Connectware by exporting the project, extracting the configuration XML from the export, and translating it into a [service commissioning file](/2-4-2/data-flows/service-commissioning-files.md). The OPC Router export format is not officially documented, but the export file is a ZIP archive containing one readable XML file with every plug-in instance, transfer object, and connection, which is enough for an AI-assisted translation. In more detail, the following topics are covered: * Understanding how OPC Router concepts map to Connectware resources * Exporting the project and extracting the configuration XML * Translating the configuration into a service commissioning file with an AI assistant * Reviewing the generated service commissioning file * Verifying the migrated data points in the [Data Explorer](/2-4-2/monitoring/data-explorer.md) A complete worked example, from export XML to service commissioning file, is available at the end of this guide. ## Prerequisites To follow this guide, you will need the following: * A running instance of Cybus Connectware with licenses for the connectors that replace your OPC Router plug-ins. * Access to the OPC Router configuration tool to run the project export. * Network access from Connectware to the systems that OPC Router currently talks to. * An AI assistant to translate the configuration. Any capable large language model (LLM) works. [Cybus Connectware GPT](/2-4-2/tools/cybus-connectware-gpt.md) is a ChatGPT assistant that already knows the service commissioning file format. * Basic knowledge of the Connectware [services](/2-4-2/data-flows/services.md) concept (for example, [service commissioning files](/2-4-2/data-flows/service-commissioning-files.md), [connections](/2-4-2/data-flows/service-commissioning-files/resources/cybus-connection.md), and [endpoints](/2-4-2/data-flows/service-commissioning-files/resources/cybus-endpoint.md)). ## How OPC Router Concepts Map to Connectware OPC Router organizes integration in plug-in instances (protocol drivers with target-system settings), transfer objects (addressable data points or database fields), and connections (visual data flows started by triggers). Note the naming difference: an OPC Router connection is the data flow, while the protocol session lives in the plug-in instance. Connectware organizes the same information in resources of a service commissioning file: | OPC Router concept | Connectware resource | Notes | | ---------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Plug-in instance | [Cybus::Connection](/2-4-2/data-flows/service-commissioning-files/resources/cybus-connection.md) | The instance settings (endpoint URL, security policy, database host) become the connection properties. | | Transfer object item | [Cybus::Endpoint](/2-4-2/data-flows/service-commissioning-files/resources/cybus-endpoint.md) | Each OPC address or database field becomes an endpoint. | | Connection (visual data flow) | [Cybus::Mapping](/2-4-2/data-flows/service-commissioning-files/resources/cybus-mapping.md) | Straight source-to-target flows become mappings; flows with logic need [Rule Engine](/2-4-2/data-flows/rule-engine.md) rules. | | Data Change trigger | Subscribe endpoint | OPC UA endpoints in Connectware are subscription-based by default. | | Time and Cron triggers | Polling interval | The trigger period becomes the endpoint interval, or the sampling interval for OPC UA. | | REST trigger | [HTTP Server](/2-4-2/connectors/servers/http-server.md) | Inbound HTTP calls that start a flow become HTTP Server resources. | | Script triggers and branching | Rule Engine or [Node-RED Workbench](/2-4-2/data-flows/node-red-workbench.md) | C# scripts have no mechanical translation. | | Template connections and variables | Parameters and definitions with `!sub` | One service commissioning file per template; one parameter set per instance. | ### Mapping Plug-Ins to Connectors The following OPC Router plug-ins have a native Connectware counterpart: | OPC Router plug-in | Connectware connector | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | OPC UA Client | [OPC UA Client](/2-4-2/connectors/shop-floor-connectors/opc-ua/opc-ua-client.md) | | OPC UA Server | [OPC UA Server](/2-4-2/connectors/servers/opc-ua-server.md) | | OPC DA | [OPC DA](/2-4-2/connectors/shop-floor-connectors/opc-da.md) | | MQTT Client, Sparkplug | [MQTT](/2-4-2/connectors/enterprise-connectors/mqtt.md), [Sparkplug B Integration](/2-4-2/guides/system-connectivity/industry-standards-interoperability/sparkplug-b-integration.md) | | REST | [HTTP/REST](/2-4-2/connectors/enterprise-connectors/http-rest.md) and [HTTP Server](/2-4-2/connectors/servers/http-server.md) | | Microsoft SQL Server | [MSSQL](/2-4-2/connectors/enterprise-connectors/mssql.md) | | MySQL/MariaDB, PostgreSQL, Oracle, ODBC | [SQL](/2-4-2/connectors/enterprise-connectors/sql.md) | | Apache Kafka | [Kafka](/2-4-2/connectors/enterprise-connectors/kafka.md) | | InfluxDB | [InfluxDB](/2-4-2/connectors/enterprise-connectors/influxdb.md) | OPC Router has no direct PLC drivers: S7, Modbus, and EtherNet/IP devices reach it through the PLC's built-in OPC UA server or a third-party OPC server. Connectware connects to [S7](/2-4-2/connectors/shop-floor-connectors/siemens-simatic-s7.md), [Modbus/TCP](/2-4-2/connectors/shop-floor-connectors/modbus-tcp.md), and [EtherNet/IP](/2-4-2/connectors/shop-floor-connectors/ethernet-ip.md) devices natively, so the migration is an opportunity to remove intermediary OPC servers. If a KEPServerEX instance sits between OPC Router and the machines, see [Migrating from Kepware KEPServerEX](/2-4-2/guides/migration/migrating-from-kepware-kepserverex.md). ### What Does Not Migrate 1:1 | OPC Router feature | Connectware approach | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SAP plug-in (RFC, BAPI, IDoc) | No counterpart. Integrate SAP through its HTTP-based APIs with the [HTTP/REST connector](/2-4-2/connectors/enterprise-connectors/http-rest.md) or an external integration layer. | | Printer, labeling, and device plug-ins | No equivalents for Zebra, Domino, Videojet, and similar plug-ins. | | Notification plug-ins (email, Telegram) | Route alerts to a consuming system over MQTT or HTTP. | | C# script triggers and branching flows | Re-implement in the [Node-RED Workbench](/2-4-2/data-flows/node-red-workbench.md) or with [FlowSync](/2-4-2/data-flows/flowsync.md) for request-response orchestration. | | Enterprise+ dynamic template instances | Template instances generated from database rows have no direct equivalent; generate service commissioning files in CI/CD instead. | | Store & Forward add-on | Handled differently: Connectware [agents](/2-4-2/data-flows/agents.md) buffer data during connection loss. | ## Exporting the OPC Router Project 1. In the OPC Router configuration tool, select **File > Export OPC Router 4 project**. 2. Select all plug-ins, connections, and templates, and save the `.rpe` file. The `.rpe` file is a ZIP archive. Rename it to `.zip` and extract it: it contains a single `OpcRouter4.xml` file with every plug-in instance and its settings, every connection with its triggers and wiring, every transfer object with its addresses, and all template variables. {% hint style="warning" %} The export format is not officially documented and can change between OPC Router versions. Treat the XML as an inventory of your own project rather than a stable interface, and record the OPC Router version alongside the export. Credentials do not reliably travel in the export: collect endpoint URLs, users, and certificates separately, and remove any values that did end up in the XML before you paste it into an AI tool. Check the data privacy terms of the tool you use; see also the privacy notes for [Cybus Connectware GPT](/2-4-2/tools/cybus-connectware-gpt.md#data-privacy). {% endhint %} For flows whose logic is hard to read from the XML wiring, supplement the export with images: right-click a connection and use **Export View** to save the visual flow as an image. ## Translating the Configuration with an AI Assistant Copy the following prompt and attach the extracted XML: {% code title="AI translation prompt" lineNumbers="true" expandable="true" %} ``` You are translating an inray OPC Router project export (the OpcRouter4.xml file extracted from an .rpe archive) into a Cybus Connectware service commissioning file (YAML). Produce one complete, valid service commissioning file with description, metadata, parameters, definitions, and resources. Structural rules: - The section lists plug-in instances. Create one Cybus::Connection per instance whose type has a Connectware connector: OPCUaPlugInConfig -> Opcua (parse host and port from , map to securityPolicy and messageSecurityMode), database plug-ins -> Mssql or Sql, MQTT plug-ins -> Mqtt, Kafka -> Kafka, InfluxDB -> Influxdb. - The section contains the visual data flows. Each flow has triggers (for example TimeTriggerConfig with a period, or data change triggers) and wired by elements. - Create one Cybus::Endpoint per OPCTransferObjectItem. The is either a NodeId ("ns=2;s=...") or a browse path starting with "bp=" (for example "bp=4:Machines/5:Press/5:Speed;"). Browse paths translate directly to the Connectware OPC UA "browsePath" property: strip the "bp=" prefix and the trailing ";". - Polling: a TimeTriggerConfig period becomes the samplingInterval and publishInterval of the OPC UA endpoints in that flow; data change triggers use the default subscription behavior. - Database transfer objects (tables, columns, queries) become endpoints on the matching SQL connector; include the query and flag it for review. - Straight source-to-target flows become Cybus::Mapping entries publishing each endpoint to a topic derived from the flow and transfer object names, lowercase kebab-case. Flows with branching, scripts (ScriptTriggerConfig), or ETL transfer objects cannot be translated mechanically: list them under "Needs redesign" with a short description of what they do. - Resolve and into service parameters; template connections become one set of resources with parameters instead of one copy per instance. - Define hosts and credentials as parameters, never hardcoded. Do not include any credentials in the output. - Skip plug-in types without a Connectware counterpart (SAP, printers, notifications) and list them at the end under "Not migrated". After the YAML, output a migration report: number of plug-in instances, transfer objects, and flows translated, all assumptions made, and every flagged item that needs manual review or redesign. [Attach the OpcRouter4.xml file. State your OPC Router version.] ``` {% endcode %} For large projects, translate one flow at a time and combine the results. Expect flows with SAP, printers, or scripts to need a redesign discussion rather than a translation. ## Reviewing the Generated Service Commissioning File Work through this checklist before installing: 1. Validate the file structure. The [Cybus Connectware Extension for VS Code](/2-4-2/tools/cybus-connectware-extension-vs-code.md) validates service commissioning files against the official schemas as you edit. 2. Check every connection against the original plug-in instance settings: endpoint URL, security policy, and database host. 3. Spot-check translated OPC addresses, both NodeIds and browse paths, with an OPC UA browser as described in [Using Connectware as an OPC UA Client](/2-4-2/guides/system-connectivity/industry-standards-interoperability/using-connectware-as-an-opc-ua-client.md). 4. Review every flow listed under "Needs redesign" and decide where its logic goes: Rule Engine, Node-RED Workbench, or a consuming system. 5. Re-enter all credentials as parameters; they were not part of the export. 6. Compare the endpoint count against the migration report of the AI assistant and the transfer object count of the project. ## Installing the Service 1. Install the service commissioning file. See [Installing Services](/2-4-2/data-flows/services/managing/installing.md). 2. Enable the service. See [Enabling Services](/2-4-2/data-flows/services/managing/enabling.md). **Result:** Connectware connects to the migrated systems directly and the connections reach the **Connected** state. {% hint style="info" %} For read-only validation, Connectware and OPC Router can usually read the same OPC UA servers and databases at the same time, which allows you to compare live values before you disable the original flows. Check the session limits of your OPC UA servers first. {% endhint %} ## Verifying the Data Open the [Data Explorer](/2-4-2/monitoring/data-explorer.md) and subscribe to the topics of the migrated service: * Every migrated transfer object publishes on its topic with plausible values. * Values match between OPC Router and Connectware for the same data point. * Database-bound flows write the expected rows through the SQL connectors. * Data arrives at the original trigger rates. ## Worked Example The following excerpt from an extracted `OpcRouter4.xml` file shows an OPC UA plug-in instance and a time-triggered flow with two transfer object items. The XML is shortened for readability; real exports carry additional attributes and default settings: {% code title="OpcRouter4.xml (excerpt, shortened)" lineNumbers="true" expandable="true" %} ```xml opc.tcp://192.168.1.100:4840 None 10000 bp=4:Machines/5:Press/7:State/5:Speed; bp=4:Machines/5:Press/7:State/9:PiecesOut; ``` {% endcode %} Applying the translation rules produces the following service commissioning file. The plug-in instance becomes an OPC UA connection, each transfer object item becomes an endpoint whose `browsePath` is the `OPCAddress` without the `bp=` prefix and trailing semicolon, and the ten-second time trigger becomes the sampling interval: {% file src="/files/qJTBnGQdUY3Fds4CO3Zf" %} {% code title="opc-router-migration-example.yml" lineNumbers="true" expandable="true" %} ```yaml description: > Service commissioning file migrated from the OPC Router flow "Press to UNS" (Example) metadata: name: OPC Router Migration Example provider: cybus homepage: https://www.cybus.io version: 1.0.0 parameters: opcuaHost: description: Host of the OPC UA plug-in instance type: string default: 192.168.1.100 opcuaPort: description: Port of the OPC UA plug-in instance type: integer default: 4840 definitions: MQTT_TOPIC_PREFIX: press-to-uns resources: # OPC UA plug-in instance (SecurityPolicy None) opcuaConnection: type: Cybus::Connection properties: protocol: Opcua targetState: connected connection: host: !ref opcuaHost port: !ref opcuaPort options: securityPolicy: None messageSecurityMode: None # Transfer object item bp=4:Machines/5:Press/7:State/5:Speed; # Time trigger period 10000 ms becomes the sampling interval pressSpeed: type: Cybus::Endpoint properties: protocol: Opcua connection: !ref opcuaConnection subscribe: browsePath: 4:Machines/5:Press/7:State/5:Speed samplingInterval: 10000 publishInterval: 10000 # Transfer object item bp=4:Machines/5:Press/7:State/9:PiecesOut; pressPiecesOut: type: Cybus::Endpoint properties: protocol: Opcua connection: !ref opcuaConnection subscribe: browsePath: 4:Machines/5:Press/7:State/9:PiecesOut samplingInterval: 10000 publishInterval: 10000 mapping: type: Cybus::Mapping properties: mappings: - subscribe: endpoint: !ref pressSpeed publish: topic: !sub '${MQTT_TOPIC_PREFIX}/speed' - subscribe: endpoint: !ref pressPiecesOut publish: topic: !sub '${MQTT_TOPIC_PREFIX}/pieces-out' ``` {% endcode %} For all OPC UA connection and endpoint properties, including `browsePath` and `browsePathPrefix`, see [OPC UA Connection Properties](/2-4-2/connectors/shop-floor-connectors/opc-ua/opc-ua-client/opcuaconnection.md) and [OPC UA Endpoint Properties](/2-4-2/connectors/shop-floor-connectors/opc-ua/opc-ua-client/opcuaendpoint.md). {% hint style="info" %} Disclaimer: OPC Router is a product of inray Industriesoftware GmbH. All product and company names are trademarks or registered trademarks of their respective owners. Cybus is not affiliated with inray Industriesoftware GmbH. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cybus.io/2-4-2/guides/migration/migrating-from-opc-router.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.