Attributes in a Model Design file | OPC UA Implementation: Stacks, Tools, and Samples | Forum

Lost password?

Home Forum OPC UA Implementation: Stacks, Tool…Attributes in a Model Design file

Attributes in a Model Design file

Andy Rehn

Member

Members

Forum Posts: 5

Member Since:
03/03/2026

Offline

10/15/2026 - 05:57

Hi,

I'm working with ModelDesign file. How does the attributes AccessLevel and WriteAccess of a property element in a ModelDesign file relate to Attributes on a node in addressspace? Example where AccessLevel and WriteAccess are used:

<opc:ObjectType SymbolicName="EXOAnalogInputType" BaseType="ua:BaseObjectType" SupportsEvents="false">
  <opc:Children>
    <opc:Property SymbolicName="UserDescription" DataType="ua:String" ModellingRule="Mandatory" WriteAccess="0"></opc:Property>
    <opc:Property SymbolicName="Title" DataType="ua:String" ModellingRule="Mandatory"></opc:Property>
    <opc:Property SymbolicName="Unit" DataType="ua:String" ModellingRule="Mandatory" AccessLevel="ReadWrite"></opc:Property>
    <opc:Property SymbolicName="Status" DataType="ua:UInt16" ModellingRule="Mandatory" Historizing="true"></opc:Property>      
  </opc:Children>
</opc:ObjectType>

Is there a complete guide that shows how the attributes are mapped? Like:

(in model design file) -> (on node in addressspace)

Historizing -> Historizing

SupportsEvents -> EventNotifier

Randy Armstrong

Admin

Forum Posts: 1696

Member Since:
05/30/2017

Offline

10/15/2026 - 22:11

The issue is how the autogenerated code deals with those attributes.

The autogenerated does not automatically copy AccessLevel and WriteAccess attributes when instances are created.

This is because there is no 100% "correct" option available and it is necessary for the users to the autogenerated classes to set these attributes to values that make sense for their application.

Similar issue may exist with SupportsEvents since actually supporting events requires the HasNotifier hierarchy be wired up and if the user application does not set up HasNotifier hierarchy properly then EventNotifier should not indicate SupportsEvent.

Historizing also have the same issue. Without wiring a historian into the application the flag needs to be false.

The same code that connects the historian is responsible for setting Historizing properly.

Andy Rehn

Member

Members

Forum Posts: 5

Member Since:
03/03/2026

Offline

10/22/2026 - 01:37

Hi,

Thanks for the answer!

I am examining the node for EXOAnalogInputType in PredefinedNodes in my NodeManager (which derives from CustomNodeManager2). I drill down to the child node representing the Unit property, and its AccessLevel is set to 1 (CurrentRead) rather than the expected 3 (CurrentReadOrWrite) according to the model design file in the post above.

I can't find any trace of this value in the address space, neither in the corresponding type nor in instances created from that type.

Why is AccessLevel a valid property in a ModelDesign file if its value is ultimately ignored?

Forum Timezone: America/Phoenix

Most Users Ever Online: 1361

Currently Online:

Guest(s) 35

Currently Browsing this Page:
1 Guest(s)