TransportsI am an engineer by training and a technologist by interest. I follow technology and every day think about what technology is important and what’s not. I also know what I like and don’t like. And I’ll tell you right now I don’t like all this Alexa technology that is being put into all sorts of home devices. I don’t want my bed, my toaster, my dishwasher, and my refrigerator all talking to me, reminding me of what I have forgotten to do.

I don’t want a reminder that there are clothes in the dryer that need to be put away, that I need to pick up milk, and it will be economical to start the dishwasher in the next half hour. Once we get there, those things will probably start saying “you never take me anywhere” and “you’re never home anymore.” I don’t need that.

But one technology that I do like, as many of you know, is OPC UA. And one of its very cool features is the transports it supports. There is a large variety of transports offered, and every device designer can tailor the transports supported for the application. Server devices can support a low end, high throughput, insecure transport layer or a highly secure, certificate-based, processor intensive transport. It’s entirely up to the Server designer which transport to choose and how many different transports to support, as they are not limited to a single transport.

Client devices, on the other hand, need to be much more sophisticated. A Client device must not only support all the various varieties of transport layers to ensure that they can access any kind of Server, they must also have the ability to interrogate a Server (or an aggregating Server) about what kind of transports are supported.

Transports, if you don’t know, are the low-level mechanisms for moving those serialized messages from one place to another. The UA specification defines a number of transports that Clients must support.


HTTP (Hypertext Transfer Protocol) is the connectionless, stateless, request-response protocol that you use every time you access a web page (the “http” in https://www.rtautomation.com/). HTTP is the standard way that a Client can request data like HTML files, images, and query results from a Server.
SOAP (Simple Object Access Protocol) is an XML messaging protocol that provides a mechanism for applications to encode messages to other applications. An application can encode a SOAP request that asks another application to perform a service or return data.

When used as an OPC UA transport, OPC UA requests and responses are encoded as SOAP requests that can be easily decoded by standard mechanisms of many IT type applications.

Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP. When you see a web URL that is preceded by “https:” it means that all communications between your browser and that website are encrypted. Just as with HTTP, SOAP is used as the request response protocol to move the OPC UA requests between Clients and Servers.

UA TCP is simple TCP-based protocol designed for Server devices that lack the resources to implement XML encoding and HTTP / SOAP type transports. UA TCP uses binary encoding and a simple message structure that can be implemented on low-end Servers.

The advantage of this ability to select a transport on the fly is that it makes OPC UA the first information technology that can EASILY interoperate at both the Machine Control communications and Enterprise levels. Most other technologies are designed for a specific application. OPC UA is more flexible in that it can provide connectivity at any level of an automation architecture.

For more information on how RTA can make your inaccessible data accessible, please visit our online gateway product catalog or speak to one of our inside sales associates by calling 262-436-4999.