It is allowed to add subtypes into the existing type hierarchy.

It is not recommended to insert new types inside the existing hierarchy, as shown in Figure 1. In the example, NewType is added as supertype of Subtype_B and Subtype_C.

If a new type is absolutely necessary, the following rules apply:

• The new type shall not add mandatory InstanceDeclarations unless they have been defined before on each subtype.
• The new type shall not define additional constraints (defined in the text of the specification), unless those constraints were already valid for all its subtypes before.
• The newly added type may be abstract or concrete.

In a nutshell, the new type shall not add anything to the subtypes that would not be allowed to be added to the subtypes directly.

It is not allowed to add new types inside the EventType hierarchy, i.e. in the part of the ObjectType hierarchy inheriting from the BaseEventType, as EventTypes are used for filtering, and new OPC UA Clients might use the new EventType as a filter in an old Server, which would not work.

Figure 1 – Example of adding types inside an existing type hierarchy

OPC UA Clients that are pre-programmed with knowledge of the type hierarchy do not need to browse the type hierarchy in the OPC UA Server. Therefore an old OPC UA Client would work with a new OPC UA Server, since all types that are built into the old OPC UA Client would exist. A new OPC UA Client would also work since the old OPC UA Server would not have any instances of the newly added types. An OPC UA Client has to expect that not all defined types will have instances.

It is allowed to add new subtypes of events that extend the existing types, but these subtypes have to maintain the concepts expressed by the parent type. A limit alarm could have a subtype that makes some of the limits mandatory or even adds more limits, but all subtypes would have to still be limit alarms.