UA-.NETStandard/tools/Opc.Ua.SourceGeneration.Core/Schema

OPC UA Model Design File Schema Documentation

Overview

The UA Model Design Schema is a proprietary schema that supports a more visual modelling experience defining OPC UA types and instances. This definition is used by the model compiler and source generator to generate code, documentation, and validate model consistency.

The schema allows modellers to:

• Define Types (ObjectType, VariableType, DataType, ReferenceType)
• Define Instances (Object, Variable, Method, Property)
• Organize entities within Namespaces
• Manage Permissions and Access Restrictions
• Create References between nodes
• Specify Default Values and Parameters

Note: This schema is not part of the official OPC UA specification. The official definition of nodes and references is in the form of .Nodeset2.xml whose schema is defined in OPC UA Part 6 - Annex F. This code is used internally to convert .Nodeset2.xml files to this schema format.

---

Table of Contents

1. Document Structure

   • Example Model Structure

2. Core Components

   • Root Element: ModelDesign
   • Namespace Organization
   • Permission Management
     • Permission Sets (Global)
     • Role-Based Permissions

3. Type System

   • Type Designs
     • ObjectTypeDesign
     • VariableTypeDesign
     • DataTypeDesign
     • ReferenceTypeDesign
   • Instance Designs
     • ObjectDesign
     • VariableDesign
     • PropertyDesign
     • MethodDesign
     • ViewDesign

4. Common Patterns

   • Node Design Pattern
   • Instance Design Pattern
   • Reference Pattern

5. Access Control

   • Access Restrictions
   • Role-Based Access

6. Complex Types

   • DataType with Fields
   • DataType with Encodings

7. Hierarchical Structure

8. Processing Workflow

9. Best Practices

   • Naming Conventions
   • Type Hierarchy
   • Validation Indicators

10. Release Status and Purpose

    • Release Status
    • Purpose

11. Schema Validation

12. Extensions

13. Related Resources

14. Summary

---

Document Structure

A valid ModelDesign XML document must:

1. Start with a <ModelDesign> root element
2. Include a TargetNamespace attribute (required)
3. Optionally define <Namespaces> and <PermissionSets>
4. Contain zero or more type and instance declarations
5. Optionally include <Extensions> for custom metadata

Example Model Structure

<?xml version="1.0" encoding="utf-8"?>
<ModelDesign
    TargetNamespace="http://example.com/MyModel"
    TargetVersion="1.0"
    TargetXmlNamespace="http://example.com/MyModel/Types.xsd"
    DefaultLocale="en">

    <Namespaces>
        <Namespace Name="MyNamespace" 
                   Prefix="Example.MyModel">
            http://example.com/MyModel
        </Namespace>
    </Namespaces>

    <ObjectType SymbolicName="MyObjectType">
        <!-- Type definition -->
    </ObjectType>

</ModelDesign>

{
  "TargetNamespace": "http://example.com/MyModel",
  "TargetVersion": "1.0",
  "TargetXmlNamespace": "http://example.com/MyModel/Types.xsd",
  "DefaultLocale": "en",
  "Namespaces": [
    {
      "Name": "MyNamespace",
      "Prefix": "Example.MyModel",
      "Content": "http://example.com/MyModel"
    }
  ],
  "ObjectTypes": [
    {
      "SymbolicName": "MyObjectType"
    }
  ]
}

---

Core Components

1. Root Element: ModelDesign

The <ModelDesign> element is the container for all model definitions.

Attributes:

• TargetNamespace (required) - The URI identifying the namespace
• TargetVersion (optional) - Version of the model
• TargetPublicationDate (optional) - Publication date (ISO 8601)
• TargetXmlNamespace (optional) - XML namespace URI (if different from TargetNamespace)
• DefaultLocale (optional, default: "en") - Default language locale

See also: Namespaces, Permission Management, Extensions

---

2. Namespace Organization

Namespaces organize OPC UA entities and create numeric indices for browse paths.

<Namespaces>
    <Namespace Name="Core" 
               Prefix="Opc.Ua"
               InternalPrefix="Opc.Ua.Server"
               XmlNamespace="http://opcfoundation.org/UA/2008/02/Types.xsd"
               FilePath="Opc.Ua.Types.xml">
        http://opcfoundation.org/UA/
    </Namespace>
</Namespaces>

{
  "Namespaces": [
    {
      "Name": "Core",
      "Prefix": "Opc.Ua",
      "InternalPrefix": "Opc.Ua.Server",
      "XmlNamespace": "http://opcfoundation.org/UA/2008/02/Types.xsd",
      "FilePath": "Opc.Ua.Types.xml",
      "Content": "http://opcfoundation.org/UA/"
    }
  ]
}

Namespace Attributes:

• Name - Symbolic identifier for the namespace
• Prefix - C# namespace for generated classes
• InternalPrefix - C# namespace for server-only types
• XmlNamespace - XML namespace URI (if different from content)
• XmlPrefix - XML namespace prefix
• FilePath - Path to separate design file
• Version - Namespace version
• PublicationDate - Publication date

---

3. Permission Management

Permission Management controls access and security for nodes.

Permission Sets (Global)

Define reusable permission configurations at the model level.

<PermissionSets>
    <PermissionSet Name="AdminPermissions">
        <RolePermission Role="Administrator">
            <Permission>All</Permission>
        </RolePermission>
        <RolePermission Role="Guest">
            <Permission>Browse</Permission>
            <Permission>Read</Permission>
        </RolePermission>
    </PermissionSet>
</PermissionSets>

{
  "PermissionSets": [
    {
      "Name": "AdminPermissions",
      "RolePermissions": [
        {
          "Role": "Administrator",
          "Permissions": ["All"]
        },
        {
          "Role": "Guest",
          "Permissions": ["Browse", "Read"]
        }
      ]
    }
  ]
}

Role-Based Permissions

Each node can have role-specific permissions. Available permissions include:

• Browse - Browse the node
• Read - Read the node value
• Write - Write the node value
• ReadHistory - Read node history
• InsertHistory, ModifyHistory, DeleteHistory
• ReceiveEvents - Subscribe to node events
• Call - Invoke methods
• AddReference, RemoveReference
• DeleteNode, AddNode
• All, AllRead, None

See also: Role-Based Access, Access Restrictions

---

Type System

The schema defines four main type categories through a type hierarchy:

graph TD
    A["NodeDesign<br/>(Base)"] --> B["TypeDesign"]
    A --> C["InstanceDesign"]
    
    B --> B1["ObjectTypeDesign"]
    B --> B2["VariableTypeDesign"]
    B --> B3["DataTypeDesign"]
    B --> B4["ReferenceTypeDesign"]
    
    C --> C1["ObjectDesign"]
    C --> C2["VariableDesign"]
    C --> C3["MethodDesign"]
    C --> C4["ViewDesign"]
    
    C2 --> C2a["PropertyDesign"]
    B1 --> B1a["EncodingDesign"]
    C2 --> C2b["DictionaryDesign"]

3.1 Type Designs (Inherits from TypeDesign)

Type designs define the structure and behavior of types in the information model.

ObjectTypeDesign

Defines the structure of objects in the information model. See Instance Designs for related ObjectDesign.

<ObjectType SymbolicName="MyObjectType" 
            BaseType="ua:BaseObjectType"
            IsAbstract="false"
            SupportsEvents="true">
    <DisplayName>My Custom Object</DisplayName>
    <Description>Describes an instance of MyObjectType</Description>
    <Children>
        <Variable SymbolicName="Status" TypeDefinition="ua:BaseVariableType" />
        <Method SymbolicName="Initialize" />
    </Children>
</ObjectType>

{
  "ObjectType": {
    "SymbolicName": "MyObjectType",
    "BaseType": "ua:BaseObjectType",
    "IsAbstract": false,
    "SupportsEvents": true,
    "DisplayName": "My Custom Object",
    "Description": "Describes an instance of MyObjectType",
    "Children": [
      {
        "Variable": {
          "SymbolicName": "Status",
          "TypeDefinition": "ua:BaseVariableType"
        }
      },
      {
        "Method": {
          "SymbolicName": "Initialize"
        }
      }
    ]
  }
}

Key Attributes:

• BaseType - Parent type (default: BaseObjectType)
• IsAbstract - Cannot instantiate if true
• SupportsEvents - Generates events
• NoClassGeneration - Skip code generation

VariableTypeDesign

Defines the structure of variables in the information model. See Instance Designs for related VariableDesign.

<VariableType SymbolicName="TemperatureType"
              DataType="xs:double"
              ValueRank="Scalar"
              AccessLevel="ReadWrite">
    <DefaultValue>
        <Double>20.5</Double>
    </DefaultValue>
</VariableType>

{
  "VariableType": {
    "SymbolicName": "TemperatureType",
    "DataType": "xs:double",
    "ValueRank": "Scalar",
    "AccessLevel": "ReadWrite",
    "DefaultValue": {
      "Double": 20.5
    }
  }
}

Key Attributes:

• DataType - The data type of the variable
• ValueRank - Scalar, Array, ScalarOrArray, OneOrMoreDimensions, ScalarOrOneDimension, Any
• ArrayDimensions - Dimensions specification
• AccessLevel - Read, Write, ReadWrite, HistoryRead, HistoryWrite, HistoryReadWrite
• MinimumSamplingInterval - Sampling rate in milliseconds
• Historizing - Supports historical data
• ExposesItsChildren - Children are exposed in address space

DataTypeDesign

Defines the structure of data types (complex types). See Complex Types for detailed examples.

<DataType SymbolicName="MyStructure"
          IsAbstract="false"
          IsOptionSet="false"
          IsUnion="false">
    <Fields>
        <Field Name="Field1" DataType="xs:int" />
        <Field Name="Field2" DataType="xs:string" IsOptional="true" />
    </Fields>
    <Encodings>
        <Encoding SymbolicName="MyStructureEncoding">
            <!-- Encoding specification -->
        </Encoding>
    </Encodings>
</DataType>

{
  "DataType": {
    "SymbolicName": "MyStructure",
    "IsAbstract": false,
    "IsOptionSet": false,
    "IsUnion": false,
    "Fields": [
      {
        "Name": "Field1",
        "DataType": "xs:int"
      },
      {
        "Name": "Field2",
        "DataType": "xs:string",
        "IsOptional": true
      }
    ],
    "Encodings": [
      {
        "SymbolicName": "MyStructureEncoding"
      }
    ]
  }
}

Key Attributes:

• IsOptionSet - Structure is an option set (bitmask)
• IsUnion - Structure is a union type
• NoArraysAllowed - Instances cannot be arrays
• ForceEnumValues - Force numeric values for enums
• NoEncodings - Skip encoding generation

Special Cases:

• OptionSet: Represents a set of flags combined with bitwise operations
• Union: Only one field is active at a time

See also: DataType with Fields, DataType with Encodings

ReferenceTypeDesign

Defines typed References between nodes.

<ReferenceType SymbolicName="MyReference"
               BaseType="ua:References"
               Symmetric="false">
    <InverseName>IsReferencedBy</InverseName>
</ReferenceType>

{
  "ReferenceType": {
    "SymbolicName": "MyReference",
    "BaseType": "ua:References",
    "Symmetric": false,
    "InverseName": "IsReferencedBy"
  }
}

Attributes:

• Symmetric - Same reference type applies in both directions

---

3.2 Instance Designs (Inherits from InstanceDesign)

Instance designs represent actual instances of types in the OPC UA address space. See Type Designs for the corresponding type definitions.

ObjectDesign

Represents an object instance in the address space. Instances of ObjectTypeDesign.

<Object SymbolicName="MyObject"
        TypeDefinition="MyObjectType"
        ModellingRule="Mandatory"
        SupportsEvents="true">
    <DisplayName>My Object Instance</DisplayName>
    <Children>
        <Variable SymbolicName="Status" />
    </Children>
</Object>

{
  "Object": {
    "SymbolicName": "MyObject",
    "TypeDefinition": "MyObjectType",
    "ModellingRule": "Mandatory",
    "SupportsEvents": true,
    "DisplayName": "My Object Instance",
    "Children": [
      {
        "Variable": {
          "SymbolicName": "Status"
        }
      }
    ]
  }
}

VariableDesign

Represents a variable instance in the address space. Instances of VariableTypeDesign.

<Variable SymbolicName="Temperature"
          TypeDefinition="TemperatureType"
          DataType="xs:double"
          AccessLevel="Read"
          ModellingRule="Mandatory">
    <DefaultValue>
        <Double>20.0</Double>
    </DefaultValue>
</Variable>

{
  "Variable": {
    "SymbolicName": "Temperature",
    "TypeDefinition": "TemperatureType",
    "DataType": "xs:double",
    "AccessLevel": "Read",
    "ModellingRule": "Mandatory",
    "DefaultValue": {
      "Double": 20.0
    }
  }
}

PropertyDesign

A specialized VariableDesign used for node properties.

<Property SymbolicName="SerialNumber"
          DataType="xs:string"
          AccessLevel="Read"
          ModellingRule="Mandatory" />

{
  "Property": {
    "SymbolicName": "SerialNumber",
    "DataType": "xs:string",
    "AccessLevel": "Read",
    "ModellingRule": "Mandatory"
  }
}

MethodDesign

Represents a method (callable operation).

<Method SymbolicName="Initialize"
        ModellingRule="Mandatory"
        NonExecutable="false">
    <InputArguments>
        <Argument Name="Parameter1" DataType="xs:int" />
    </InputArguments>
    <OutputArguments>
        <Argument Name="Result" DataType="xs:string" />
    </OutputArguments>
</Method>

{
  "Method": {
    "SymbolicName": "Initialize",
    "ModellingRule": "Mandatory",
    "NonExecutable": false,
    "InputArguments": [
      {
        "Name": "Parameter1",
        "DataType": "xs:int"
      }
    ],
    "OutputArguments": [
      {
        "Name": "Result",
        "DataType": "xs:string"
      }
    ]
  }
}

ViewDesign

Represents a view in the address space.

<View SymbolicName="MyView"
      ContainsNoLoops="true"
      SupportsEvents="false" />

{
  "View": {
    "SymbolicName": "MyView",
    "ContainsNoLoops": true,
    "SupportsEvents": false
  }
}

---

Common Patterns

Node Design Pattern

All nodes share common attributes and child elements:

graph LR
    A["NodeDesign"] --> B["Attributes"]
    A --> C["Child Elements"]
    
    B --> B1["SymbolicName"]
    B --> B2["SymbolicId"]
    B --> B3["NumericId/StringId"]
    B --> B4["WriteAccess"]
    B --> B5["ReleaseStatus"]
    B --> B6["Purpose"]
    
    C --> C1["BrowseName"]
    C --> C2["DisplayName"]
    C --> C3["Description"]
    C --> C4["Children"]
    C --> C5["References"]
    C --> C6["RolePermissions"]
    C --> C7["AccessRestrictions"]

Key Attributes (on all nodes):

• SymbolicName - Local identifier (required)
• SymbolicId - Globally unique identifier (auto-generated if not specified)
• NumericId - UA numeric node ID
• StringId - UA string node ID (alternative to NumericId)
• IsDeclaration - Node is declared elsewhere (no code generation)
• WriteAccess - Bitmask of writable attributes
• PartNo - Which part of specification defines it
• Category - Comma-separated categories
• ReleaseStatus - See Release Status
• Purpose - See Purpose
• IsDynamic - Node value may change during runtime

See also: Instance Design Pattern, Validation Indicators

Instance Design Pattern

Instances (Object, Variable, Method) inherit from InstanceDesign:

<Object SymbolicName="MyInstance"
        Declaration="ua:BaseObjectType"
        TypeDefinition="MyObjectType"
        ModellingRule="Mandatory"
        MinCardinality="0"
        MaxCardinality="0"
        PreserveDefaultAttributes="false"
        DesignToolOnly="false">
    <!-- Content -->
</Object>

{
  "Object": {
    "SymbolicName": "MyInstance",
    "Declaration": "ua:BaseObjectType",
    "TypeDefinition": "MyObjectType",
    "ModellingRule": "Mandatory",
    "MinCardinality": 0,
    "MaxCardinality": 0,
    "PreserveDefaultAttributes": false,
    "DesignToolOnly": false
  }
}

Modelling Rules:

• None - Not constrained
• Mandatory - Must be present in instances
• Optional - May be present
• MandatoryShared - Shared mandatory instance
• OptionalPlaceholder - Optional placeholder
• MandatoryPlaceholder - Mandatory placeholder
• ExposesItsArray - Array elements exposed separately
• CardinalityRestriction - Cardinality is restricted

See also: Node Design Pattern

Reference Pattern

References create semantic relationships between nodes. See ReferenceTypeDesign for type definitions.

<References>
    <Reference IsInverse="false" IsOneWay="false">
        <ReferenceType>ua:HasComponent</ReferenceType>
        <TargetId>MyTargetNode</TargetId>
    </Reference>
</References>

{
  "References": [
    {
      "IsInverse": false,
      "IsOneWay": false,
      "ReferenceType": "ua:HasComponent",
      "TargetId": "MyTargetNode"
    }
  ]
}

Attributes:

• IsInverse - Reference direction is inverted
• IsOneWay - Only forward reference exists

---

Access Control

Access Restrictions

Nodes can specify security requirements:

<AccessRestrictions>SigningRequired</AccessRestrictions>
<AccessRestrictions>EncryptionRequired</AccessRestrictions>

{
  "AccessRestrictions": [
    "SigningRequired",
    "EncryptionRequired"
  ]
}

Available Restrictions:

• SigningRequired - Messages must be signed
• EncryptionRequired - Messages must be encrypted
• SessionRequired - Active session required
• SessionWithSigningRequired - Session + signing
• SessionWithEncryptionRequired - Session + encryption
• (AndApplyToBrowse variants) - Restrictions apply to browse operations

See also: Role-Based Access, Permission Management

Role-Based Access

Assign permissions to roles using RolePermissions. See Role-Based Permissions for available permission types.

<RolePermissions Name="MyPermissions" DoNotInheirit="false">
    <RolePermission Role="Administrator">
        <Permission>All</Permission>
    </RolePermission>
    <RolePermission Role="User">
        <Permission>Browse</Permission>
        <Permission>Read</Permission>
    </RolePermission>
</RolePermissions>

{
  "RolePermissions": {
    "Name": "MyPermissions",
    "DoNotInherit": false,
    "RolePermissions": [
      {
        "Role": "Administrator",
        "Permissions": ["All"]
      },
      {
        "Role": "User",
        "Permissions": ["Browse", "Read"]
      }
    ]
  }
}

See also: Permission Management, Access Restrictions

---

Complex Types

DataType with Fields

Fields define the structure of complex DataType definitions.

<DataType SymbolicName="UserIdentity">
    <Fields>
        <Field Name="UserId" DataType="xs:int" Identifier="1" />
        <Field Name="UserName" DataType="xs:string" Identifier="2" />
        <Field Name="Email" DataType="xs:string" Identifier="3" IsOptional="true" />
        <Field Name="Permissions" DataType="xs:unsignedInt" BitMask="Permissions" />
    </Fields>
</DataType>

{
  "DataType": {
    "SymbolicName": "UserIdentity",
    "Fields": [
      {
        "Name": "UserId",
        "DataType": "xs:int",
        "Identifier": 1
      },
      {
        "Name": "UserName",
        "DataType": "xs:string",
        "Identifier": 2
      },
      {
        "Name": "Email",
        "DataType": "xs:string",
        "Identifier": 3,
        "IsOptional": true
      },
      {
        "Name": "Permissions",
        "DataType": "xs:unsignedInt",
        "BitMask": "Permissions"
      }
    ]
  }
}

Field Attributes:

• Name - Field identifier
• DataType - Type of the field
• Identifier - Unique numeric identifier
• ValueRank - Scalar or Array
• ArrayDimensions - Dimensions if array
• BitMask - Named bitmask for flag fields
• AllowSubTypes - Subtypes allowed
• IsOptional - Field is optional

See also: DataType with Encodings

DataType with Encodings

Encodings define how DataType instances are serialized.

<DataType SymbolicName="MyStructure">
    <Encodings>
        <Encoding SymbolicName="MyStructureXml" 
                  TypeDefinition="ua:DataTypeEncodingType">
            <DisplayName>XML Encoding</DisplayName>
        </Encoding>
        <Encoding SymbolicName="MyStructureBinary" 
                  TypeDefinition="ua:DataTypeEncodingType">
            <DisplayName>Binary Encoding</DisplayName>
        </Encoding>
    </Encodings>
</DataType>

{
  "DataType": {
    "SymbolicName": "MyStructure",
    "Encodings": [
      {
        "SymbolicName": "MyStructureXml",
        "TypeDefinition": "ua:DataTypeEncodingType",
        "DisplayName": "XML Encoding"
      },
      {
        "SymbolicName": "MyStructureBinary",
        "TypeDefinition": "ua:DataTypeEncodingType",
        "DisplayName": "Binary Encoding"
      }
    ]
  }
}

See also: DataType with Fields

---

Hierarchical Structure

Complete Example with Hierarchy

Demonstrates how ObjectType, Property, Variable, and Method definitions create a complete hierarchy.

<ObjectType SymbolicName="DeviceType">
    <DisplayName>Device</DisplayName>
    <Children>
        <Property SymbolicName="SerialNumber" DataType="xs:string" />
        <Variable SymbolicName="Status" DataType="xs:string" />
        <Method SymbolicName="Start" />
        <Method SymbolicName="Stop" />
        <Object SymbolicName="Parameters" TypeDefinition="ParameterGroupType">
            <Children>
                <Property SymbolicName="Timeout" DataType="xs:int" />
                <Property SymbolicName="RetryCount" DataType="xs:int" />
            </Children>
        </Object>
    </Children>
</ObjectType>

{
  "ObjectType": {
    "SymbolicName": "DeviceType",
    "DisplayName": "Device",
    "Children": [
      {
        "Property": {
          "SymbolicName": "SerialNumber",
          "DataType": "xs:string"
        }
      },
      {
        "Variable": {
          "SymbolicName": "Status",
          "DataType": "xs:string"
        }
      },
      {
        "Method": {
          "SymbolicName": "Start"
        }
      },
      {
        "Method": {
          "SymbolicName": "Stop"
        }
      },
      {
        "Object": {
          "SymbolicName": "Parameters",
          "TypeDefinition": "ParameterGroupType",
          "Children": [
            {
              "Property": {
                "SymbolicName": "Timeout",
                "DataType": "xs:int"
              }
            },
            {
              "Property": {
                "SymbolicName": "RetryCount",
                "DataType": "xs:int"
              }
            }
          ]
        }
      }
    ]
  }
}

---

Processing Workflow

graph TD
    A["XML Design File"] --> B["Validator"]
    B --> C["Assigns Numeric IDs"]
    B --> D["Generates BrowseNames"]
    B --> E["Generates DisplayNames"]
    B --> F["Generates Descriptions"]
    C --> G["Code Generator"]
    D --> G
    E --> G
    F --> G
    G --> H["Generated Code"]
    G --> I["Generated Documentation"]

The workflow:

1. Design - Model is authored in XML
2. Validation - Validator checks consistency (see Schema Validation)
3. Augmentation - Auto-generate missing attributes
4. Generation - Create code and documentation
5. Output - Type classes, instances, constants

---

Best Practices

Naming Conventions

• SymbolicName: Use PascalCase (e.g., TemperatureType, MyObject)
• BrowseName: Same as SymbolicName (auto-generated)
• DisplayName: Human-readable label
• ClassName: For types, remove 'Type' suffix (auto-generated)

Type Hierarchy

<!-- ✓ Good: Proper inheritance -->
<VariableType SymbolicName="AnalogItemType" 
              BaseType="ua:VariableType" />

<VariableType SymbolicName="TemperatureType" 
              BaseType="AnalogItemType" />

<!-- ✗ Avoid: Unnecessary abstraction levels -->

{
  "comment": "Good: Proper inheritance",
  "VariableTypes": [
    {
      "SymbolicName": "AnalogItemType",
      "BaseType": "ua:VariableType"
    },
    {
      "SymbolicName": "TemperatureType",
      "BaseType": "AnalogItemType"
    }
  ]
}

See also: Type System

Validation Indicators

• Always specify SymbolicName (see Node Design Pattern)
• Use IsDeclaration="true" for external references
• Include descriptions for public types
• Assign unique NumericId values
• Use ModellingRule consistently (see Instance Design Pattern)

---

Release Status and Purpose

Release Status

Controls visibility and stability of nodes. Used in Node Design Pattern:

<ObjectType SymbolicName="ExperimentalType" 
            ReleaseStatus="Draft">
    <!-- Type under development -->
</ObjectType>

<ObjectType SymbolicName="StableType" 
            ReleaseStatus="Released">
    <!-- Production-ready type -->
</ObjectType>

{
  "ObjectTypes": [
    {
      "SymbolicName": "ExperimentalType",
      "ReleaseStatus": "Draft"
    },
    {
      "SymbolicName": "StableType",
      "ReleaseStatus": "Released"
    }
  ]
}

Purpose

Indicates intended usage. Used in Node Design Pattern:

<DataType SymbolicName="RequestType" Purpose="ServicesOnly">
    <!-- Used only in service definitions -->
</DataType>

<DataType SymbolicName="TempStruct" Purpose="Testing">
    <!-- Used for testing only -->
</DataType>

{
  "DataTypes": [
    {
      "SymbolicName": "RequestType",
      "Purpose": "ServicesOnly"
    },
    {
      "SymbolicName": "TempStruct",
      "Purpose": "Testing"
    }
  ]
}

---

Schema Validation

The validator performs these checks on ModelDesign documents:

✓ Consistency - All References are valid
✓ Uniqueness - No duplicate SymbolicIds
✓ Completeness - All required attributes present
✓ Type Safety - DataTypes match References
✓ Circular References - No invalid cycles

---

Extensions

Custom Extensions can be added for tool-specific metadata:

<ModelDesign TargetNamespace="..." >
    <!-- Standard content -->
    <Extensions>
        <Extension>
            <CustomMetadata>
                <Property Name="Author">John Doe</Property>
                <Property Name="Version">1.0</Property>
            </CustomMetadata>
        </Extension>
    </Extensions>
</ModelDesign>

{
  "TargetNamespace": "...",
  "Extensions": [
    {
      "CustomMetadata": {
        "Author": "John Doe",
        "Version": "1.0"
      }
    }
  ]
}

See also: Root Element: ModelDesign

---

Related Resources

• OPC UA Specification
• UA Part 3 - Address Space Model
• UA Part 5 - Information Model
• UA Part 6 - Mappings