How to Evaluate an OPC UA Edge Gateway for an Industrial IoT Project

Evaluate an OPC UA edge gateway by specifying its role, the values it must expose or collect, the client's security requirements and the evidence needed for acceptance. For a Robustel EG5120 project using compatible E2C Factory software, distinguish reading an upstream OPC UA source from providing an OPC UA Server to another system. Then test the actual endpoints, node mappings and application behavior. The phrase “supports OPC UA” is a starting point for evaluation, not a completed compatibility assessment.

Illustrative industrial environment; final implementation is project specific.

Key Takeaways

• Specify whether the gateway collects OPC UA data or exposes a server to clients.
• Match the selected EG5120 software and firmware before following a worked tutorial.
• Evaluate node meaning and actual client behavior as carefully as connectivity.
• Record unsupported or untested requirements explicitly instead of inferring full protocol coverage.

In This Guide

• Which role is required?
• What belongs in the evidence matrix?
• How should a bench test work?
• How do you make the decision?

Which OPC UA role does the project require?

Write the requirement as a sentence with a direction. For example: “The plant's application must read selected gateway tags through an OPC UA Server.” This is more useful than “the gateway needs OPC UA” because it identifies who connects and where the values originate.

The Factory overview lists OPC UA among southbound protocols and OPC UA Server among northbound interfaces. These are separate integration roles. Confirm the applicable edition in the version comparison, and evaluate each role independently if the project needs both.

For a northbound server evaluation, identify the source of the internal tags first. The official OPC UA Server guide starts with live collected tags, then maps them for clients. The gateway should not be evaluated only as an empty endpoint with no representative data.

The tutorial's tested model is EG3120. EG5120 support must be checked using the Factory application compatibility page. Record the actual EG5120 build and carry out model-specific validation; the tutorial is not a test report for your configuration.

What belongs in the OPC UA evidence matrix?

Create one row for every mandatory interface requirement and assign an evidence status: documented, demonstrated, accepted or unresolved. Avoid merging those states into a single checkmark.

This is a project evaluation matrix, not a list of automatically supported features. Add requirements such as history access, alarms or particular security policies only if the project needs them, and request specific supporting evidence.

Record the consumer's exact software build. A general diagnostic client can help isolate a problem, but its success does not settle the behavior of the customer's production application.

How should the OPC UA bench test work?

Use a small set of safe representative tags. Include a numeric value, a state and a value that changes in a controlled way. The objective is to evaluate the complete meaning of the interface without creating a large point database first.

For the documented Factory server workflow, verify live source data, configure the server, map the selected tags and connect with the chosen client. The guide describes server connection settings and mapped data choices. Follow the current configuration instructions for your release rather than copying values from its screenshots.

Capture a source-to-client comparison for each tag. Record the internal source name, mapped node, expected interpretation and observed client result. If a processed value is exposed, record that choice so a client developer does not apply the same conversion again.

Illustrative interface evaluation using a controlled test environment.

Then test the events that matter to the intended operation. Reconnect the approved test client and check whether it resumes the expected observation. Restart the test service under an agreed procedure and check the endpoint and node mapping again. Change only safe simulated data when assessing update behavior.

If the application will write values, keep that evaluation separate from monitoring. Identify the permitted node, approved range, source equipment and restoration step before testing. A readable node does not justify an unreviewed production write.

Keep the evidence direct. A screenshot of a browser tree proves that nodes were visible at that moment. A sequence showing the known source change and the corresponding client update provides stronger evidence for the measurement requirement.

How do you turn test results into a decision?

Accept a requirement when its stated test passes on the intended configuration and the accountable owner accepts the evidence. Do not accept a general category because one example within it worked.

An unresolved mandatory security setting is a decision blocker even when a less restrictive bench setting connects. An untested client version remains untested even if a diagnostic tool works. Record these distinctions in the matrix so commercial and engineering teams make the same decision.

For partial fit, describe the boundary precisely: which node set, software version, direction and operating conditions were evaluated. If another component is required, identify its owner and add its interface to the test plan. Avoid hiding an extra integration dependency behind the gateway selection.

Retain the matrix with sample node mappings and captured results. Reopen the relevant rows when the gateway app, client release, source definition or access arrangement changes. This turns a one-time demonstration into a maintainable interface baseline.

Frequently asked questions about OPC UA gateway evaluation

Does an OPC UA Server feature mean the gateway can read every OPC UA source?

No. Server exposure and source collection are different roles. Verify the relevant driver or server function and test the intended counterpart for each direction.

Is a UaExpert test enough for production acceptance?

It can provide useful diagnostic evidence. Final acceptance should also cover the actual client application, its version, required settings and expected data interpretation.

Can the EG3120 tutorial prove my EG5120 installation works?

It demonstrates the documented workflow on its stated test setup. Confirm EG5120 application requirements separately and validate your own gateway and software combination.

Should write access be enabled during an initial reading test?

Only when a separately approved test requires it. Start with the monitoring requirement and review any equipment-changing operation with the responsible OT team.

What should you do next?

Prepare a short OPC UA evidence matrix and three representative tags for the Robustel EG5120 evaluation. Use the official server guide where that role applies, and request specific evidence for any mandatory requirement the guide does not establish.

About the Author

Mark, Technical Support Engineer at Robustel

Mark is a Technical Support Engineer at Robustel with hands-on experience in industrial networking and edge connectivity. He helps customers plan, deploy, configure, and troubleshoot industrial IoT solutions, including cellular routers, edge gateways, and LoRaWAN systems. His work spans technical support, product training, configuration review, and practical deployment guidance for reliable and repeatable field operations across global projects and long-term operational support.