Feature Request: Support for OPC UA interface for encrypted communication

[eliasprohaszka]

I am currently evaluating the use of Fanuc.NET in a production environment where data security and encrypted communication are mandatory requirements.

As far as I can see, the current implementation primarily uses the standard Fanuc Focus/Ethernet communication. I would like to ask if there are any plans to implement an OPC UA interface in the future?

Why this would be useful:

Security: OPC UA provides built-in mechanisms for encryption and signing (X.509 certificates), which is often required by modern IT security policies.

Standardization: It would allow easier integration into unified Scada/IIoT architectures.

Interoperability: Providing an OPC UA server/client wrapper within this library would make it even more versatile for Industry 4.0 applications.

Is this something currently on your roadmap?

[Rufus31415]

Thank you for your question and for highlighting the importance of security and interoperability in production environments.

At the moment, there are no concrete plans to add an OPC UA interface to Fanuc.NET, and there are a few important reasons behind this.

First, from a licensing perspective, OPC UA integration introduces significant constraints. Using the GPL version would require the entire SDK to be distributed under GPL as well, which is not aligned with the current distribution model. The RCL license would avoid this constraint, but it comes with a substantial entry cost and raises additional questions regarding redistribution rights.

Second, OPC UA does not fully cover the functional scope of Fanuc.NET. While it is well suited for standardized data access and secure communication, it does not support certain key features provided by the SDK, such as file transfers, remote program execution, or full machine supervision. As a result, an OPC UA layer would only partially address the existing capabilities and would still require the native communication stack alongside it.

That said, the interest in OPC UA for security (encryption, certificates), standardization, and Industry 4.0 interoperability is fully understood. It is something that could be reconsidered in the future if there is strong demand and a viable approach that balances licensing, cost, and functional coverage.

In the meantime, if secure communication is a strict requirement, it may be worth considering external solutions such as network-level encryption (e.g., VPN, secure gateways) or integrating Fanuc.NET within a secured infrastructure.

https://opcfoundation.org/license/rcl.html
https://opcfoundation.org/license/gpl.html

[Rufus31415]

Additionally, it would be technically feasible to introduce OPC UA support by implementing the stack independently, rather than relying on the official SDK. This approach would avoid licensing constraints while still providing the core benefits of OPC UA, especially for secure and standardized data access.

Similarly, for file access, an SFTP-based approach could be implemented. This is something I have already done successfully in the past with Universal Robots integrations, and it proved to be both reliable and compliant with modern security requirements.

Regarding machine control, on newer firmware versions (v10+), it should also be possible to remotely start jobs using CGTP over HTTPS, which opens the door to secure remote execution without relying solely on legacy protocols.

Overall, this complete feature set (OPC UA for data, SFTP for file transfer, HTTPS/CGTP for control) is not particularly complex to design, implement, and validate in a controlled environment.

If this direction aligns with your needs, feel free to contact me by email so we can discuss this further, including your timeline and specific requirements.

[eliasprohaszka]

Thank you for the detailed technical breakdown and the potential roadmap for implementing OPC UA, SFTP, and HTTPS/CGTP.

Currently, we have implemented all our application features using the existing SDK and rely on network-level encryption to secure the communication. In our estimation, this approach should be sufficient to meet CRA (Cyber Resilience Act) compliance for the time being.

However, to be truly on the safe side and future-proof, having "defense in depth" by using both network encryption and protocol-level security would be the ideal scenario.

If you decide to include these secure interfaces (OPC UA, SFTP, etc.) in your long-term roadmap, we would certainly welcome it. It would be a great addition to the library’s versatility in highly regulated environments.

We will keep this in mind and might reach out via email if our requirements or timelines become more urgent regarding these specific features. Thanks again for the insights!