{ "id": "7133d16a-98ce-4e3d-be94-01d7e7f9141c", "created_at": "2026-04-06T00:06:14.085638Z", "updated_at": "2026-04-10T13:12:43.553249Z", "deleted_at": null, "sha1_hash": "1d7a975517cfa224085b240dcd8ef1a42025abdb", "title": "Still a Thrill: OPC UA Device Discovery", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 49600, "plain_text": "Still a Thrill: OPC UA Device Discovery\r\nBy John Rinaldi\r\nPublished: 2016-04-08 · Archived: 2026-04-05 18:23:53 UTC\r\nA long while back, I when I started working on industrial\r\nconnectivity, I had hair. It’s now gone. Completely gone. I’ve lost the hair but I’ve gained 30 years of experience.\r\nAnd over all those years in the automation industry, the Discovery mechanism in OPC UA is one of the most\r\nfascinating things I’ve seen.\r\nOPC UA is a very flexible and sophisticated mechanism for Client devices to find and identify Server devices.\r\nThe traditional mechanism for matching a Client (also called an Initiator or Master device) to a Server (or a Target\r\nor Slave device) is for the user to identify the Server to the Client during some sort of configuration process.\r\nThese mechanisms are effective for the kinds of factory floor applications we’ve used in the past. In fact, for low-level sensor/actuator networks, they would still be recommended.\r\nBut OPC UA is designed to function equally well on the factory floor and the Enterprise, so what’s really\r\ninteresting is how OPC UA created a more robust and flexible mechanism that works equally well on the factory\r\nfloor with embedded devices as it does in the Enterprise with IT devices.\r\nOPC UA designed Device Discovery using the Service Oriented Architecture (SOA) model. What makes SOA so\r\ninteresting, and the backbone of a lot of Enterprise and Internet applications, is that there is a standard mechanism\r\nfor Clients to discover Server devices, interrogate them to see what services they offer, and connect to them. OPC\r\nUA extends the SOA model to define a process in which Clients can find Server devices that choose to reveal\r\nthemselves, interrogate them to determine the various ways that the Client can interact with them, and determine\r\nwhat capabilities they have that might be of interest.\r\nTo understand OPC UA Device Discovery there is a term that you may have heard but not fully understood. That\r\nterm is endpoint. An endpoint is a connection to a device that offers some specific functionality, that is sometimes\r\nonly available through that specific connection. For example, you can think of the programming port on a\r\nhttps://www.rtautomation.com/rtas-blog/still-a-thrill-opc-ua-device-discovery/\r\nPage 1 of 3\n\nProgrammable Controller as an endpoint. It uses a specific physical layer with a specific transport to accomplish\r\ndownloading a program. That programming port is an endpoint, and it’s dedicated to programming, it will differ\r\nfrom every other communication port (endpoint) on the programmable controller.\r\nTypical Ethernet devices in Industrial Automation have a single endpoint. ProfiNet IO devices have an endpoint\r\nthat supports ProfiNet IO connections with cyclic and acyclic message transfer. EtherNet/IP devices have an\r\nendpoint that supports CIP (Common Industrial Protocol) messaging. Modbus TCP devices have an endpoint that\r\nsupports Modbus messages over Ethernet.\r\nThe only real cases where devices we are familiar with in Industrial Automation have multiple endpoints are those\r\ndevices that support multiple protocols. If a device supports EtherNet/IP and Modbus TCP, then there will actually\r\nbe two: http://192.168.0.100:502/ for Modbus TCP and http://192.168.0.100:44818/ for EtherNet/IP. That hasn’t\r\nbeen important to us in the past because a Modbus Client or an EtherNet/IP Scanner device (Client/Initiator)\r\n“knows” to send messages to a Modbus Server or an Adapter device (Slave/Initiator) using those endpoints.\r\nGame-changing Endpoints\r\nBut now, with OPC UA, endpoints are not only much more important, they are much more sophisticated.\r\nOPC UA devices can have any number of endpoints. Some may have only one or two. Others might have as many\r\nas five or ten.\r\nSome endpoints will use HTTP, HTTPS, or UA Secure Channel as the transport.\r\nSome endpoints will require signed messages, others will require signed and encrypted messages, and still others\r\nmay not use any security at all.\r\nSome endpoints will exist for particular purposes, such as the Discovery endpoint, which Clients use to get the\r\nendpoint information. Those endpoints will usually not provide the functionality that you might find on other\r\nendpoints.\r\nTo understand OPC UA Device Discovery, it is important to understand the basic steps that are used in the Device\r\nDiscovery process where an OPC UA Client device finds, interrogates, and connects to OPC UA Server devices:\r\n1. A Server powers on, and if it chooses to provide its own Discovery service support, it opens its Discovery port\r\nfor messages from Client devices that want endpoint information.\r\n2. If a Server chooses to let another Server provide Discovery services, it registers itself with Local Discovery\r\nServers (LDS) or multicast Discovery Servers (LDS-ME). The Discovery servers may be resident on the same\r\nplatform as the Server, or on a platform someplace else on the network. Note that some Servers may choose to\r\nremain private and only be available to Clients that are configured to know about them.\r\n3. A Client that finds a Server in an LDS can retrieve the application description for the Server and information on\r\naccessing the Server’s Discovery endpoint where it can get more detailed information on the Server.\r\n4. If a Client is interested in connecting to a Server, it uses the Server’s Discovery endpoint to get the list of\r\nendpoints supported. The information on each endpoint includes the transport and security it supports.\r\nhttps://www.rtautomation.com/rtas-blog/still-a-thrill-opc-ua-device-discovery/\r\nPage 2 of 3\n\n5. If the Client finds an endpoint that meets its application requirements, security requirements, and transport\r\nrequirements, it begins the connection process with the Server on that endpoint.\r\nThat’s a very unique and sophisticated way of connecting two devices together. I find it fascinating. It might be\r\nmore fascinating if I still had hair but I’ve given up on that!\r\nJohn Rinaldi is a renowned automation strategist and the CEO of Real Time Automation (RTA). A leading voice\r\nin industrial networking, John has authored six books on essential protocols like EtherNet/IP, OPC UA and\r\nIndustrial Ethernet, along with 500+ technical articles. He is a sought-after speaker and consultant, known for his\r\nability to simplify complex data communication challenges and drive innovation in global industrial applications.\r\nSource: https://www.rtautomation.com/rtas-blog/still-a-thrill-opc-ua-device-discovery/\r\nhttps://www.rtautomation.com/rtas-blog/still-a-thrill-opc-ua-device-discovery/\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://www.rtautomation.com/rtas-blog/still-a-thrill-opc-ua-device-discovery/" ], "report_names": [ "still-a-thrill-opc-ua-device-discovery" ], "threat_actors": [], "ts_created_at": 1775433974, "ts_updated_at": 1775826763, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/1d7a975517cfa224085b240dcd8ef1a42025abdb.pdf", "text": "https://archive.orkl.eu/1d7a975517cfa224085b240dcd8ef1a42025abdb.txt", "img": "https://archive.orkl.eu/1d7a975517cfa224085b240dcd8ef1a42025abdb.jpg" } }