Define and manage tags in your UNS.

ReferenceModulesUNSUIAsset | Tags | UserTypes | Enumerations | Services | Monitor


Two distinct "reference" concepts in FrameworX — do not confuse

The word "reference" covers two different mechanisms in FrameworX. Both appear on this page, so disambiguating up front:

(a) The Reference tag type — covered in the Reference Type section below. A runtime tag whose .Link property points to another tag of the same UserType, used for runtime pointer / alias behavior (one display driving many equipment instances). See the Tag Reference Open Display Example.

(b) A Reference-type UDT member — covered on the sibling UNS UserTypes Reference page. A member declared with Type=Reference whose per-instance value points to another tag's /Attr envelope (for example, Mixer_M101.feedsInto = Reactor_R101/Attr). This is the FX representation of an OWL owl:ObjectProperty — an ontology relation between named individuals — and round-trips through the RDF/OWL importer and exporter. See Industrial Ontology Integration How-to.

 UNS Tags (Reference) represent real-time variables and their associated historical records, providing a structured way to model process information by linking to physical devices, databases, or calculated values. 

Tags in the Unified Namespace provide:

  • Real-time data representation
  • Historical record association
  • Device communication mapping
  • Hierarchical organization
  • Type-safe data handling
  • Array and template support

Tags form the foundation of the solution's data model, connecting field devices to visualization, logic, and storage.


Tag Types

Built-in Types

Type.NET TypeDescriptionRange
DigitalInt32Binary value0 or 1
IntegerInt32Whole numbers±2,147,483,647
LongInt64Extended integers±9.2×10¹?
DoubleDoubleFloating point±1.79×10³??
DecimalDecimalHigh precision28-29 significant digits
TextStringUnicode text2GB max
JsonStringJSON structured dataBuilt-in parsing
DateTimeDateTimeOffsetDate and timeYear 0001-9999
TimeSpanTimeSpanDurationDays to milliseconds
GuidGuidUnique identifier128-bit
DataTableDataTableIn-memory tableStructured data
ImageByte[]Binary contentAny size
TimerInt32Time patternsMultiple modes

Timer Types

ModeBehaviorUse Case
SquareWaveToggle 0/1 at intervalBlinking, heartbeat
PulseMomentary 0→1→0Triggers, events
DelayOffHold value then resetTOF timer
ComparerDaily scheduleTime-based control

Reference Type

Dynamic tag addressing:

// Set reference target
@Tag.Reference1.Link = @Tag.TankFarm/Tank1/Level.GetName();



// Use reference
double level = @Tag.Reference1.Value;


Configuration Properties

PropertyDescriptionRequired
NameUnique tag identifierYes
TypeData type selectionYes
PathAsset tree locationNo
ArrayArray size (0 to N)No
StartValueInitial value at startupNo
Parameters

Type specific settings

No
Min/MaxValue limitsNo
ScaleMin/MaxEngineering scaleNo
RetentiveValue persistenceNo
DomainServer/Client scopeNo
VisibilityExternal access levelNo
FormatDisplay formattingNo
UnitsEngineering unitsNo
EnumerationNumber to String (show result in Tag1.ValueAsStringNo
DefaultSymbolSymbol used when dropping/pasting tags on a displayNo
LabelsSemicolon-delimited alternative names. Imports from skos:altLabel, searchable via search_uns and runtime_search_uns. Runtime-mutable and retentive — scripts, bindings, and (planned) operator UI can edit at runtime; writes persist across restarts. Unbounded text (10.1.5+).No
SourceIriFull source IRI for the individual. External-system join key. Populated by the ontology importer, editable at design time only. Immutable at runtime — the IRI is the tag's identity; if a rename is needed, re-import with owl:sameAs. Unbounded (10.1.5+).No
AttributesJSON column for ontology annotations not covered by other columns (dcterms:*, alt-language labels keyed rdfs:label@pt, skos:note, owl:versionInfo, custom predicates). Runtime-mutable and retentive — edit via @Tag.X.SetAttribute(...) or the (planned) operator UI (10.1.5+).No
DescriptionDocumentation (1024 char)No

Ontology metadata columns (10.1.5+)

Tags in 10.1.5 carry three ontology columns alongside their real-time data: Labels, SourceIri, and Attributes. These columns populate from RDF/OWL individuals imported by the ontology importer and round-trip back through Export UNS → RDF / JSON.

  • Labels — semicolon-delimited alternative names. Imports from skos:altLabel and skos:hiddenLabel. Searchable via search_uns (Designer) and runtime_search_uns (runtime) with one canonical scoring algorithm.
  • SourceIri — full source IRI for the individual. External-system join key. Preserved on re-export, so round-trip is lossless.
  • Attributes — JSON column for ontology annotations not covered by other columns (dcterms:*, alt-language labels keyed rdfs:label@pt, skos:note, owl:versionInfo, custom predicates).

Mutability & retention

Tag ontology columns follow a class-vs-instance split shared with UserType and member-def columns (see UNS UserTypes Reference):

LayerSourceIriLabelsAttributes
UserType

Design-time · immutable identity

Design-time

Design-time

Member-def

Design-time

Not modeled

Design-time

Tag (this page)

Design-time · immutable identity

Runtime-editable · retentive

Runtime-editable · retentive

Tag Labels and Attributes are the only ontology columns an operator, script, or UI can mutate at runtime. Writes land in the retentive database and survive restarts. Use promote_retentive_attributes before export to roll runtime overlays back into the cold-start data so the exporter produces a deterministic RDF/OWL file. Bindings can read all three columns but writes go through the property setter (script) or the planned operator UI — never through binding-write directly. SourceIri is the tag's ontology identity and never changes at runtime: if a rename is needed, re-import with owl:sameAs.

See Industrial Ontology Integration How-to for the full model.


AI / MCP page action (10.1.5+)

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

  • designer_action("export_graph", "rj") — mirrors the Export UNS toolbar dropdown. Accepts four W3C RDF formats — format=rj (RDF/JSON, default; the format the ontology importer round-trips and the most compatible with graph stores like GraphDB / Stardog / Fuseki), format=jsonld (JSON-LD), format=turtle (alias ttl), and format=ntriples (alias nt). All four are native emitters in 10.1.5. The exported file lands in the solution's Exchange folder.

The action is listed in the tabActions array returned by get_state() only when the Tags tab is active. See Export your UNS to RDF/OWL/GraphDB for the broader export reference.


Creating Tags

Method 1: Asset Tree

  1. Navigate to Unified Namespace → Asset Tree
  2. Right-click folder or click New Tag icon
  3. Enter tag name and properties

Method 2: Tags Grid

  1. Go to Unified Namespace → Tags
  2. Options:
    • Click New Item for dialog
    • Type directly in Name column
    • Paste from external source

Method 3: Import

  • Copy from another solution
  • Import from CSV files
  • Use Solution Import Tools
  • EngWrapper API

Tag Parameters, Type Specific Settings

Deadband

Limits value updates:

Absolute: ±5 units from last value
Percentage: 10% change required

EnumerationSet

Map values to text:

0 → "Off"
1 → "On"
2 → "Auto"

Domain Configuration

DomainScopeUse Case
ServerGlobal across all clientsDevice data, shared values
ClientLocal to each sessionUser settings, local states

Visibility Levels

LevelExternal AccessUse Case
PrivateNoneInternal only
ProtectedRead-onlyMonitor only
PublicRead/WriteFull access

Affects: OPC UA Server, MQTT Broker, TcpDataAccess


Retentive Options

SettingSavesUse Case
NoneNothingTemporary values
ValueOnlyValue onlyOperator setpoints
PropertiesAll including valueComplete state
PropertiesOnlyAll except valueConfiguration

Storage: Dataset.DB.Retentive database


Format Strings

Numeric Formats

N0    → 123        (no decimals)
N2    → 123.45     (2 decimals)
C     → $123.00    (currency)
P     → 12.34%     (percentage)
X     → 7B         (hexadecimal)
E     → 1.23E+02   (scientific)

DateTime Formats

d     → 3/15/2024  (short date)
T     → 14:30:00   (long time)
yyyy-MM-dd HH:mm:ss → 2024-03-15 14:30:00

Array Configuration

Array size N creates elements [0] to [N]:

Array = 5 creates:
Tag[0], Tag[1], Tag[2], Tag[3], Tag[4], Tag[5]
(6 elements total)

DataTable Tags

Using Queries

@Tag.DataTableTag = @Dataset.Query.MyQuery.SelectCommand();


Manual Population

@Tag.DataTableExample.StartBlockSet();
@Tag.DataTableExample[1].Column1 = value1;
@Tag.DataTableExample[2].Column2 = value2;
@Tag.DataTableExample.CommitBlockSet();



Runtime Attributes

Core Properties

PropertyTypeDescription
ValueTag TypeCurrent value
QualityIntegerOPC quality (0/64/192)
TimestampDateTimeOffsetLast change time

Quality Codes

  • 0: Bad quality
  • 64: Uncertain quality
  • 192: Good quality

Quality on a comms or sync drop

When the connection that feeds a tag is lost — a device communication failure (read retries exhausted, node or channel failure) or a broken redundancy / remote-server sync link — the runtime does not leave the affected tags frozen at their last-good value pretending to still be live. Instead it forces Quality to Bad (0) and raises the change as a normal Changed event, so every consumer — displays, scripts, alarms, the Historian, OPC UA / MQTT publishers — sees the staleness on the next update rather than reading a stale value as if it were current.

Lifecycle

EventValueQualityRaised as

Connection drops (read retries exhausted, or node / channel / sync failure)

Last-good value is retained (the runtime does not blank it)

Bad (0)

Changed event

Reconnect attempt also fails

Unchanged

Stays Bad (0)

Connection recovers (next successful read)

Fresh value from the field

Good (192) resumes

Changed event

The value being kept (rather than blanked) means a display still shows the last reading, but it is now flagged Bad — the quality, not the value, is what tells you it is no longer live.

Design consequence — react to .Quality, not just .Value

Because a dropped source holds its last .Value while only .Quality flips to Bad, control, interlock, and permissive logic must test .Quality — not the value alone. A rung that reads only @Tag.X.Value will keep acting on a stale number after the source is gone; gating it on @Tag.X.Quality == 192 (Good) makes the logic fail safe when the data goes stale. The same applies to alarm conditions and any calculation that aggregates field data.


Additional Configuration

The TagNames are frequently reference in these other configuration Tables:

DevicesPoints

  • Node: Communication node
  • Address: PLC/device address
  • AccessType: Read/Write/ReadWrite

AlarmsItems

  • Condition: Trigger logic
  • Groups: Alarm categorization
  • Limits: Threshold values

HistorianTags

  • Table: Storage location
  • Deadband: Recording threshold
  • DeadbandType: Absolute/Percentage

Best Practices Checklist 

  • Use meaningful names - Follow naming conventions
  • Set appropriate types - Match data characteristics
  • Configure retentive - Preserve critical values
  • Apply deadbands - Reduce unnecessary updates
  • Document tags - Use Description field
  • Organize in assets - Logical hierarchy
  • Set security - Control access levels

Troubleshooting

Tag not updating:

  • Check device communication
  • Verify Quality = 192
  • Review deadband settings
  • Confirm not disabled

Wrong value format:

  • Check Format string
  • Verify Units configuration
  • Review scale settings

Array issues:

  • Confirm index in range
  • Check array size setting
  • Verify element access

Retentive not working:

  • Check database connection
  • Verify retentive setting
  • Review database permissions

In this section...