Thanks for the quick answer. The NodeId.parseNodeId() seems to work fine (at least in my particular case).

As for the rest of your very informative answer…

In cases where nodeIds are not string then how would one get a specific OPC UA tag node (without navigating to it)? Would you be forced to use whatever NodeIds the server provides or is there some way to translate between the human readable tag notation (i.e. similar to the tag notation of OPC DA)? I mean from a configuration point of view if I use an OPC Server, like Kepware (I have not yet gotten far enough to create one using your SDK), to create a structure such as a “Stations” folder, a “Fare Gates” sub-folder, and some leaf nodes representing my fare gate devices (or a sub folder for each device with a bunch of leaf signals) then, ideally, I want to be able to refer to these tags by something like “Stations.FareGates.FG01.State” as opposed to some arbitrary nodeId assigned by the server.

I guess I could browse the OPC Server on startup and create a dictionary between the node Display Names (including the entire hierarchical parental Display Names to create a pseudo OPC DA tag) and the corresponding server node Ids but this seems to me like functionality that should already exist. Otherwise I could need to parse the tag and compare Display Names at each level to determine which node to navigate to until I reach the leaf.

It seems that OPC UA somewhat obfuscates access to tags by introducing this concept of nodes. If I recall OPC DA (or at least some client implementations there of) does a similar thing with subscriptions (i.e. subscribed tags have client handles which used to update data) but the toolkits generally converted this back to a OPC DA tag, value and timestamp notation so that the user only used the OPC DA tag notation (and the client handles were all transparent to the user).

Thanks for the answer. It was informative.

I understand that the OPC UA specs treat the data differently so there may not be the concept of a OPC DA tag but from a user stand point there still exists a OPC DA tag like concept because this is how many of the OPC UA Servers are configured. For example, when configuring a Kepware OPC UA server, you still have a hierarchy in which your signals exist. In such a implementation, a unique signal is typically referred to by providing its complete path in the address space separated by slashes (to mimic Windows/Linux file system’s folder notations) or separated by dots (to mimic an OPC DA tag notation).

I understand that because of the way OPC UA works, it can get at data in many other ways besides the classic OPC DA tag notation but I don’t see the concept of the OPC DA tag notation going away any time soon because it mimics the way that data is added to most OPC UA Servers. Of course, this does not mean that the OPC DA tag notation has to be used to actually store the information but I believe there will always be a need for some sort of a translation function which can use something similar to the OPC DA tag notation (which basically indicates the location of the signal in the OPC Server configuration) and translate it to whatever the server is using to actually store the data (in this case nodes).

If it would not be too much trouble, could you post a quick example of how to use the TranslateBrowsePathToNodeId() function. As I said, the JavaDoc is great at documenting functions but simple examples are usually worth a 1000 words of explanation.