OPC UA defines two attributes containing naming information about an OPC UA Node, the BrowseName and the DisplayName.

Recommendations for DisplayName will be given in a later version of this document.

The BrowseName is of DataType QualifiedName, containing a NamespaceIndex and a String. Unless the BrowseName is defined in some other Namespace or there is some specific handling for the BrowseName, the Namespace for the BrowseName should be the one the Node is defined in (i.e. the same Namespace as the NodeId). Nodes defined in a Companion Specification should use the Namespace of the Companion Specification for their NodeIds and BrowseNames.

For the string-part the following naming conventions apply:

All BrowseNames should be PascalCase (also known as upper camel case), that is, all words written without spaces, and the first character of each word is upper case, the other characters are lower case. Examples: ReferenceType, BaseObjectType, Int32

If an acronym or abbreviation is used, PascalCase should also be used. Examples: PortMacAddress (where MAC is an acronym for Media Access Control), NodeId (where ID is an abbreviation for identification), UInt32 (where U is an abbreviation for unsigned).

In general, it is recommended to only use letters, digits or the underscore (‘_’) as characters for the BrowseName for TypeDefinitions (ObjectTypes, VariableTypes, DataTypes, ReferenceTypes and InstanceDeclarations), unless it is explicitly defined like “<” and “>” for optional placeholders. This also applies for field names of Structure DataTypes and EnumStrings or EnumValues of Enumerations.

Remark: If special chars like “&”, “<”, etc. are used, the UaNodeSet should define the optional SymbolicName for that Node. This can then be used for code generation.

There is no recommendation on the use of prefixes. Companion specifications may use a prefix because it suits their model. For example, if the Vision Companion Specification were to define types based on generic concepts (say a state machine), then using the prefix “Vision” may make sense (as in “VisionStateMachineType”).

The BrowseNames for ObjectTypes should be suffixed with “Type”: Examples: ServerType, NamespaceMetadataType, BaseEventType.

The BrowseNames for VariableTypes should be suffixed with “Type”. If there is an ambiguity with other Nodes, then the suffix “VariableType” should be used. Examples: PropertyType, BaseDataVariableType.

The BrowseNames for DataTypes depend on the type of DataType.

• For Structured DataTypes (subtypes of the Structure DataType) the suffix should be “DataType”. Examples: RedundantServerDataType, TimeZoneDataType. Note that the base OPC UA specification does not always follow this pattern.
• Enumeration DataTypes (subtypes of the Enumeration DataType) should not have a suffix. If suffix is used, it should be “Enum”. Examples: NodeClass, ServerState.
• Built-in DataTypes can only be defined by the base OPC UA specification. They should not have a suffix. Examples: String, Int32, Byte.
• Simple DataTypes (subtypes of the built-in DataTypes) should not have a suffix. Examples: Image, UtcTime, LocaleId.

The BrowseNames for ReferenceTypes should not have a suffix. It should describe the relationship from the source to the target. Relationships are typically described as verbs. When using a noun, it should be prefixed with a verb like “Has”. Examples: HasComponent, HasEffect, HasChild, Organizes, Aggregates.

The InverseName of a ReferenceType is only provided for asymmetric References. It should be the inverse Name of the BrowseName, e.g. ComponentOf as the inverse for HasComponent.

The BrowseNames for Objects, Variables, Methods and Views have no specific rules.

The BrowseNames for TypeDefinitionNodes (ObjectTypes, VariableTypes, and DataTypes) shall be unique (as defined in the base OPC UA specification). That means, that you need to make sure that you do not create duplicates inside the Namespace you are creating.

As OPC UA Clients typically only display the string-part of the BrowseName (and thus not the NamespaceIndex), it is desirable not to use the same name across Namespaces. As there are many Companion Specifications, this cannot be guaranteed, but should be avoided as much as possible, for example by not using names from the base OPC UA specification.

For InstanceDeclarations the BrowsePath shall be unique (defined in the base OPC UA specification). OPC UA Servers are allowed to treat BrowseNames in a case-insensitive manner. OPC UA Clients shall consider case sensitivity of the BrowseNames. Since OPC UA Servers might not handle case sensitivity, information models should not rely on case sensitivity for the uniqueness of BrowsePaths, but instead define BrowsePaths that are also unique when not considering case sensitivity. For example, one TypeDefinitionNode should not have the Properties “Id” and “ID”. Instead, prefix the name with the intended use, such as “NetworkId” and “DeviceId”.

When creating Structured DataTypes, each field of a structure must have a unique name (as defined in the base OPC UA specification). The naming convention is to use PascalCase for those names. Examples: Offset, DaylightSavingInOffset

Note: In many Companion Specifications, and in the base OPC UA specifications, lower camel case (e.g. first word starts with a lower character) is used in the specification. However, the UaNodeSet uses PascalCase, and thus the OPC UA Server provides everything as PascalCase.

When creating Enum DataTypes, each possible value of an Enum must have a unique name. The naming convention is to use PascalCase for those names. Examples: NoConfiguration, Running.

When creating a UaNodeSet for a Companion Specification, the file name should be “Opc.Ua.<ShortName>.NodeSet2.xml”. For vendor-specific UaNodeSets the file name should end with “NodeSet2.xml”.

OPC 10000-3 defines rules for NamespaceUris.

When creating a NamespaceUri for a Companion Specification, the template for Companion Specifications already suggests the URI “http://opcfoundation.org/UA/<short name>”. As a general recommendation, also for vendor-specific NamespaceUris, the use of %-escaped characters is strongly discouraged.