In OPC UA an AddressSpace is separated into Namespaces, where each Namespace defines the owner of the address space contained in it. The MDIS Namespace shall not be modified in any manner, it is owned by MDIS. Any implementation (custom types / instances) shall be in a separate Namespace from the MDIS Namespace.

Any custom types or subtypes of the standard MDIS Types, as defined in Section 10.5.2 should be separated from instances via Namespaces. This enables custom types to be shared across DCS vendors and SPCS vendors during early phases of project development and allows the DCS vendors to begin implementation of the custom types within the DCS software. It also allows reuse of types between projects.

When UANodeSet files are passed from the SPCS vendors to the DCS vendors, the whole address space is to be exchanged (i.e. the exchanged UANodeSet files shall include the MDIS Namespace and any custom Namespaces). A Namespace can be in a single UANodeSet file and multiple files are provided or the entire address space can be in a single UANodeSet file. Having all Namespaces shall enable the DCS vendors to understand any forward References as forward References can create ambiguity within developed UANodeSet files.

The length of the namespace URLs used for defining Namespaces should be less than 128 characters. This is to enable smaller devices like controllers to be able to store Namespaces. NamespaceUri usually reference back to the company that is the owner of the Namespace.

The NodeIds should be integers. If using strings, the length of the NodeIds shall be less than 32 characters. This shall enable smaller devices like controllers to process NodeIds efficiently.

NodeIds shall be fixed. When a Server restarts NodeIds shall not be changed. NodeIds should not be reused on a project. Any change in NodeIds shall require Clients to reconfigure the connection based on new generated UANodeSet files. Once a Nodeset file is delivered to a DCS vendor from the SPCS vendor the NodeIds in the file are fixed. Future NodeSet files might add or delete nodes. But in any future Nodeset file shall not change the Nodeid of any Objects that have been delivered in the prior NodeSet file.

For custom types the instance hierarchy shall be represented via HasComponent (standard OPC UA Reference) or a custom ReferenceType that has been subtyped from HasComponent or Organizes References only.