A power-systems integrator needed nine QuickServer gateways to expose NovaTech Orion RTU data to OPC UA clients. Chipkin helped turn a blocked DNP3 Ethernet pilot into a working OPC UA handoff by defining the right client/server direction, standardizing the application path, and validating the result with UaExpert.
The customer team had already proven that live telemetry could move from the Orion-side equipment into the QuickServer data arrays. The harder part was making the application engine present that data as an OPC UA server the downstream/client tools could actually browse. The pilot needed a validated DNP3 client to OPC UA server workflow, a confirmed application path for the target deployment, and a tested sample configuration that the customer’s engineers could verify directly in UaExpert.
At a Glance
- Industry: Power systems / SCADA integration
- Location: Philippines
- Customer: Energy systems integrator and distributor
- Client role: Local engineering partner for a NovaTech deployment
- Facility type: Utility SCADA pilot / lab validation environment
- Project scale: 9 QuickServer units: 5 single-port and 4 dual-port
- Upstream/server device: NovaTech Orion RTU / Orion I/O / Bitronics Meter
- Downstream/client system: Reliance HMI and UaExpert
- Protocols: From: DNP3 Ethernet → To: OPC UA
- Chipkin product: Chipkin QuickServer CAS-QS-3510-3212
- Project start: June 2023
Architecture: NovaTech Orion RTU / Bitronics Meter → DNP3 Ethernet → Chipkin QuickServer → OPC UA → Reliance HMI / UaExpert
DNP3 Ethernet to OPC UA Challenge
The project was not blocked by basic protocol compatibility. It was blocked by direction, firmware state, and proof. The customer needed the QuickServer protocol engine to behave as a DNP3 client against NovaTech Orion telemetry, then expose those live values through an OPC UA server that Reliance and UaExpert could browse. Early samples pointed at the wrong side of that handoff, which meant the DNP3 side could look partially healthy while the downstream/client browse step still failed.
A second obstacle was commissioning clarity. During field testing, the customer confirmed that Orion-side DNP3 communication and point mapping were working, but the OPC UA server side was not opening as expected. In practice, that left the customer with live data in the QuickServer data arrays but no reliable way to prove the OPC UA server side end to end until the application path and test method were fully standardized.
The project also had real delivery pressure behind it. The same integration path had to work across both single-port and dual-port QuickServer variants, and the customer paused a follow-on order for 14 more units until the pilot was resolved. That made the public value here more concrete than a generic lab exercise: the team needed a repeatable DNP3 roles and levels setup on the source side, a usable OPC UA NodeID model on the server side, and documentation that reduced guesswork during commissioning.
Why Chipkin
This was a strong fit for Chipkin because the problem crossed protocol direction, application readiness, and field validation. Chipkin QuickServer provided the gateway platform, but the real value came from locking down the DNP3 client to OPC UA server direction and sending a tested sample that the customer could compare against their own bench setup. UaExpert-based validation was more important here than a generic off-the-shelf gateway pitch.
The Solution
Chipkin positioned Chipkin QuickServer as a DNP3 client on the protocol engine, polling the Orion-side equipment and writing those values into the shared data arrays. The application engine then exposed the same data as an OPC UA server for downstream/client tools. For the validated sample, the QuickServer OPC UA server was published on TCP port 20000, and the customer used UaExpert to confirm the browse and read path.
The decisive move was standardizing the validated application path. Chipkin confirmed the required setup for the pilot, delivered a tested DNP3 client to OPC UA server configuration, and provided a validation flow the customer could repeat against UaExpert before broader rollout.
That work narrowed the project to a field-proven outcome the customer could actually validate: read-oriented DNP3 telemetry exposed to OPC UA clients. The support thread also clarified an important boundary for future projects. In this implementation, the successful path was DNP3 data exposed to OPC UA clients for browsing and reads. OPC UA write-through back into DNP3 controls was not the proven outcome and should not be assumed during project scoping.
DNP3 to OPC UA Integration Results
Project proof points:
- 9 QuickServer units were covered in the pilot across both single-port and dual-port hardware variants.
- Live DNP3 telemetry reached the QuickServer data arrays before the customer-side team validated the OPC UA server browse path.
- A validated application path and tested sample configuration standardized the DNP3 client → OPC UA server handoff.
- UaExpert communication was customer-confirmed after the corrected setup was applied.
Before the final validated application path and server/client direction were in place, the customer could see DNP3-side progress but could not get a dependable OPC UA server presentation for Reliance and UaExpert.
After the validated setup and DNP3 client to OPC UA server sample were in place, the customer’s engineers confirmed that UaExpert could communicate with the QuickServer and read live data from the data arrays.
“Our team was able to make the UAexpert communicate with the Chipkin Fieldserver — it was able to give the data from its Data Arrays to UAExpert.”
— SCADA integrator, energy systems integrator, Philippines
Have a Similar DNP3-to-OPC-UA Project?
Need to expose DNP3 telemetry to an OPC UA client without replacing the upstream RTU? Chipkin can help scope the firmware requirements, define the right client/server direction, and validate the handoff before field commissioning. Tell us about your project.