Hello,

We have a very useful mechanism using ConditionClassId, ConditionClassName and ConditionSubClassId in the ConditionType model. While defining events model for OPC 40451-1 for Tightening Systems, we wanted to reuse the similar filtering mechanism for simple event types since this concept is applicable even for various types of events which DOES NOT need any states or acknowledgement and helps the end user applications in filtering the events based on the classification.

Proposal:
Add the similar properties for ConditionClassId, ConditionClassName, ConditionSubClassId and ConditionSubClassNames as part of Event model in BaseEventType.
It can be added as a separate interface and both BaseEventType and ConditionType can implement it or move those properties to BaseEventType which will ensure that both the options are available.