One of the key goals of OPC UA is to communicate information, not just data. In order to do so, it is important that meaningful metadata is attached, starting with object names.

The names of objects are intended to tell objects apart and straightforwardly clarify what the object is, i.e. they must be human readable avoiding serials, UIDs, uncommon acronyms and other prefixes and suffixes that limit the human understanding whenever possible.

Developers shall name objects according to the following rules and principles:

CamelCase: the CamelCase capitalisation practice will be used for all names. Moreover, the developer shall comply with the whitepaper OPC11030 UA Modeling Best Practices.

Names shall be unique at their hierarchy level: no two servers provided by the same OEM shall have the same name twice, no two machine modules in the same server shall have the same name twice, no two loading points in the same machine module will have the same name twice and so on.

For instance, applying the principles above, it is acceptable to name a server adding a suffix to the machine name with a machine serial or UID e.g. Maker123, Maker 456 because no other alternative ensuring uniqueness is given. Prefixing makes the name less readable and shall be avoided.

Like function, like name: functionally equivalent objects will carry the same name. For example, each instance of a paper loading point in different machine modules will be named PaperLoadingPoint.

If a machine contains multiple objects with the same name, then the name will be completed with a suffix that allows to distinguish the objects with the same function. To continue the previous example, PaperLoadingPoint1 and PaperLoadingPoint2 are acceptable. Please, note that two paper loading points, for tipping paper and cigarette paper, will not be specialised by a suffix but a functional prefix is required i.e. TippingPaperLoadingPoint, CigarettePaperLoadingPoint because their function is different.

Name for brevity: names shall not contain redundant information and in particular information that is carried by the name of a parent object. Thus the name of a component of the SomeMachineModule shall not contain SomeMachineModule or any other string (serial, UID or similar) identifying the machine module, because the information is already captured by the name of the parent object given the inherently hierarchical structure of the TMC nodeset.

The description property and display name that belong to each object/variable instance contained in a TMC server will provide a short phrase in plain English that explains what the instance is and that an average user familiar with the domain can understand.