UNS UserTypes Reference

Create reusable equipment templates (UserTypes).

Reference → Modules → UNS → UI → Asset | Tags | UserTypes | Enumerations | Services | Monitor

Ontology Metadata (10.1.5+)

Every UserType carries ontology metadata alongside the familiar configuration properties. Import populates these columns from RDF/OWL source files, export serializes them back to triples, and semantic search ranks matches across them. See Industrial Ontology Integration How-to for the full model.

Member-def ontology columns (10.1.5+)

The UDT member grid gained two ontology columns in 10.1.5:

Why no Labels column on member-def: property-level synonyms (skos:altLabel on data properties) are rare in real industrial ontologies (IOF, ISA-88, ISA-95) — altLabels cluster at the class level. DisplayText already covers the primary human-readable member name.

Mutability & retention

The ontology columns follow a class vs. instance split that matches W3C and industrial-ontology conventions: IRIs are identity (immutable everywhere); Labels are skos:altLabel synonyms (edited on the class at design time, on tag instances at runtime); Attributes is an extensibility bag (design-time at class and member-def levels, runtime-mutable only at tag level).

Bindings can read all three columns on every layer; writes go through script (@Tag.X.SetAttribute(...)) or the Designer editors — never through bindings directly. For RDF/OWL export, per-tag runtime mutations on Labels / Attributes must be snapshotted back to the cold-start data with promote_retentive_attributes before running the exporter.

AI / MCP page action (10.1.5+)

When Designer is navigated to the UserTypes page, the following action is exposed via the designer_action MCP tool:

• designer_action("relationship_graph") — mirrors the Knowledge Graph toolbar button. Generates an interactive HTML view (pan, zoom, filter via cytoscape.js) and opens it in the default browser. A Mermaid Markdown side-car lands next to the HTML in the Exchange folder under Visualizations/ for diff and source-control use.

The action is listed in the tabActions array returned by get_state() only when the UserTypes tab is active. See Generate a visual report of your UNS for the broader visual-report reference.

Creating UserTypes

1. Navigate to Unified Namespace → UserTypes
2. Click New button
3. In dialog:
   • Name: Template identifier
   • Description: Documentation
4. Click OK
5. Add members in grid:
   • Type in first row
   • Press Enter to add
   • Configure properties per member

UserType Properties

Using UserTypes

Creating Tags from Templates

1. Go to Unified Namespace → Tags
2. Click New Item
3. In Type dropdown, select template
4. Tag inherits all template members

Template Instance Example

Template: Motor
Members:
  - Running (Digital)
  - Speed (Double)
  - Temperature (Double)
  - AlarmStatus (Integer)

Tag: Motor1 (Type: Motor)
Access:
  @Tag.Motor1.Running
  @Tag.Motor1.Speed
  @Tag.Motor1.Temperature
  @Tag.Motor1.AlarmStatus

When the UserType represents an ontology-imported equipment class (10.1.5+)

When the UserType comes from an OWL ontology import (e.g., S88_Unit auto-created from s88:Unit by import_graph_model), instantiate it TWICE per real-world entity to capture both halves of the dual-shape pattern:

• One naked UserType-instance Tag at <path>/<entityName> — live equipment members (Temperature, Speed, Status) fed at runtime by Devices, Scripts, or simulators.
• One /Attr Tag at <path>/<entityName>/Attr — static ontology metadata members (rdfs:label, dcterms:identifier, manufacturer, classification) with StartValue defined. The importer creates this one automatically.

Both tags live as siblings under the auto-created folder. Conceptual containers (Enterprise / Site / Area / Cell with only Name + Description literal members) typically use /Attr-only. See Industrial Ontology Integration How-to → Two paradigms for the full pattern.

Nested Templates

Templates can contain other templates:

Template: PumpStation
Members:
  - Pump1 (Type: Motor)
  - Pump2 (Type: Motor)
  - FlowRate (Double)
  - Pressure (Double)

Access:
  @Tag.Station1.Pump1.Running
  @Tag.Station1.Pump2.Speed

Per-Instance Start Values on Nested Members

Available from FrameworX 10.1.6. A per-instance start value also reaches members of a nested UserType, not only direct members. Address the nested member with a dot-separated path, for example Drive.MaxHz or Drive.Leaf.Speed. The path is accepted when it ends on a basic value member of the type. Each instance keeps its own values: a start value set on one instance does not change other instances or the UserType definition.

A name not ending on a basic value member is skipped, and the skip message states the rule. This applies to a member typed as a UserType, a Reference member, a slash-separated path and a member missing from the type.

When you work through the AI Designer tools, set these values in the UnsTagsProperties table, with the dotted path as the member Name. In 10.1.6, reading back a tag's per-instance settings lists direct members only, so a nested start value is stored but not listed on read. In 10.1.5, per-instance start values apply to direct members only.

Base Type Inheritance

A UserType can declare another UserType as its Base Type (the BaseUserType property). This creates a parent-child relationship: the child automatically receives all of the parent's members and stays in sync when the parent changes.

How it works

• Inherited members are not shown in the Designer. The child's member grid in the Designer only shows the members defined directly on that type. Members from the base type are not listed there — to see or edit them, open the base type itself.
• Inherited members appear in the Asset Tree and at runtime. When a tag is created using the derived type, all members — both inherited and own — are fully available in the Asset Tree and accessible at runtime (e.g., @Tag.Motor1.Speed).
• Inherited members stay in sync. Any change to a member in the base type — name, range, units — is immediately reflected in every derived type without any action needed on the child.
• The child can add its own members. Additional rows defined on the derived type exist only on that type and are fully editable in the Designer.

Example

Base type: Motor
Members defined in Designer:
  - Running: Digital
  - Speed: Double (0-1800 RPM)
  - Temperature: Double (0-200 C)

Derived type: PremiumMotor (Base Type: Motor)
Members shown in Designer (own only):
  - PowerFactor: Double
  - EfficiencyClass: Text

At runtime / in Asset Tree, PremiumMotor tags expose all members:
  - Running, Speed, Temperature  (from Motor)
  - PowerFactor, EfficiencyClass (own)

Setting the Base Type

1. Navigate to Unified Namespace → UserTypes.
2. Select the UserType row to configure.
3. In the properties panel, pick the parent UserType from the BaseUserType dropdown.
4. The child is now linked to the base. Its own member grid shows only the child's direct members; the inherited ones appear when the type is used in the Asset Tree or at runtime.

Security Settings

Member Configuration

Supported Base Types

• Digital
• Integer
• Long
• Double
• Decimal
• Text
• DateTime
• Custom Templates

Array Members

Template: TankFarm
Members:
  - Tanks (Type: Tank, Array: 10)

Access:
  @Tag.TankFarm1.Tanks[0].Level
  @Tag.TankFarm1.Tanks[1].Temperature

Relative Addressing

For device communication:

Template: AnalogInput
Members:
  - Value (RelativeAddress: ".PV")
  - Status (RelativeAddress: ".ST")

Device mapping automatically appends to base address

Important Notes

Common Use Cases

Motor Template

Members:
  - Running: Digital
  - Speed: Double (0-1800 RPM)
  - Current: Double (0-100 Amps)
  - Temperature: Double (0-200 °C)
  - HoursRun: Long
  - LastMaintenance: DateTime

Tank Template

Members:
  - Level: Double (0-100 %)
  - Temperature: Double (-50-150 °C)
  - Pressure: Double (0-10 Bar)
  - HighAlarm: Digital
  - LowAlarm: Digital
  - Product: Text

Production Line

Members:
  - Station1: Motor
  - Station2: Motor
  - ConveyorSpeed: Double
  - ProductCount: Integer
  - BatchID: Text
  - QualityScore: Double

Best Practices Checklist 

• Plan template hierarchy - Design before implementation
• Use meaningful names - Clear member identification
• Document templates - Describe purpose and usage
• Standard units - Consistent engineering units
• Reuse templates - Avoid duplication
• Version control - Track template changes
• Test thoroughly - Verify all members

Troubleshooting

Template not appearing:

• Save after creation
• Check for naming conflicts
• Verify no circular references
• Review template hierarchy

Members not accessible:

• Confirm tag uses template type
• Check member names
• Verify array indices
• Review security settings

Values not retained:

• Check retentive settings
• Verify database connection
• Review member configuration
• Test with simple template

In this section...