Skill Discovery Services

Understand the three connection patterns for external data in the UNS: Local Tags + Device Points, Linked Tags (DataLink), and Dynamic Tags (Asset). Learn when to use each, how Discovery Services extend the namespace, and the DataLink shortcut for hybrid workflows.

AI Integration → Platform Skills Library → Skill Discovery Services

FrameworX has two independent systems for getting external data into the Unified Namespace: the Device Module and Discovery Services. They share nothing architecturally. Some protocols (MQTT, OPC UA) are available in both, but the workflow and mental model are completely different. This skill teaches the three connection patterns and when to use each.

When to Use This Skill

Use when the user mentions or needs:

• Connecting to external data sources without creating individual device points
• TagProvider, Tag Discovery, Discovery Services, or dynamic tags
• DataLink property, linked tags, or auto-managed communication
• Asset() syntax for dynamic data binding
• Choosing between Device Module and Discovery Services
• Large-scale IoT/IIoT with dynamic or changing tag structures
• Understanding the difference between local tags, linked tags, and dynamic tags

Do NOT use when:

• The user wants traditional SCADA device communication (Channel → Node → Points) — that's the Device Module, use protocol-specific skills
• The user only needs simulated data with ValueSimulator
• The user is building displays without external connectivity

Key Concept: Two Independent Systems

DEVICE MODULE                           DISCOVERY SERVICES
(Pillar 2: Devices)                     (Technology under Pillar 1: UNS)
---------------------------             ---------------------------------
• Define local tags FIRST               • NO local tags needed
• Create Channel ? Node ? Points        • Give address, system discovers
• Explicit polling, scan rates          • On-demand, auto-managed
• ~100 protocols                        • ~17 protocols (discovery-capable)
• Full control, deterministic           • Dynamic, flexible
• Governance: LOCAL                     • Governance: EXTERNAL

Critical rule for AI: Never create UnsTags for data that will be accessed through Discovery Services dynamic tags. The whole point is zero local tags. Only create UnsTags when:

• Using the Device Module (traditional pattern)
• Using DataLink (hybrid pattern — you want local tag governance but auto-managed communication)
• You need alarms or historian on specific dynamic data points

The Three Connection Patterns

These are not stages of development — they are three equally valid architectural patterns chosen based on data characteristics.

Pattern 1: Local Tags + Device Points (Traditional SCADA)

Define tags locally in UNS, then map them to physical device addresses through the Device Module.

When to use:

• Regulatory compliance (FDA, EPA) requiring deterministic behavior
• Safety-critical control loops
• Legacy protocols without discovery (Modbus, BACnet, DNP3, serial)
• Explicit timing requirements (custom scan rates per address)
• Full audit trail requirements

Configuration workflow:

1. Create tags in UNS (UnsTags)
2. Create Device Channel with protocol
3. Create Device Node with station address
4. Create Device Points mapping tags to addresses
5. Configure AccessType for polling behavior

Access syntax: @Tag.FolderPath/TagName or Tag.FolderPath/TagName.Member

Modules involved: UNS (tags) + Devices (channel, node, points, access types)

Pattern 2: Linked Tags — DataLink Property (Hybrid)

Create local tags in UNS but set the DataLink property to a Discovery Services path. The runtime automatically manages communication — no Device Module configuration needed.

When to use:

• You want local tag governance (tag fields, alarms, historian, metadata) BUT
• You don't want to configure Device channels/nodes/points
• Multi-site deployments with standard tag models but changing sources
• Enterprise data integration where tag names must be stable
• Systems with many unused points (communication activates on-demand only)

Configuration workflow:

1. Create tags in UNS (UnsTags)
2. Set the DataLink property to the external path
3. A Discovery Services connection for that protocol must exist
4. Runtime auto-manages communication when the tag is accessed

DataLink field example:

Tag: Plant1/TankLevel
Type: Float
DataLink: /MQTT/plant/tank01/level

Access syntax: @Tag.Plant1/TankLevel — same as any local tag. The DataLink binding is transparent.

Key behavior:

• Communication activates only when the tag is accessed (on-demand)
• If nobody reads the tag, no polling occurs (resource efficient)
• All UNS features work: alarms, historian, min/max, retentive, engineering units
• The DataLink path must match a path reachable through an existing Discovery Services connection

Modules involved: UNS only (tags with DataLink). No Device Module tables.

Pattern 3: Dynamic Tags — Asset() Syntax (Zero Configuration)

Direct binding to external paths without creating any local tags. Discovery Services dynamically discovers and extends the UNS namespace. Tags are created in the real-time database (RTDB) on-demand when accessed.

When to use:

• Data structure is dynamic or unknown upfront — the external system defines what exists
• Monitoring/visualization applications (not tight SCADA control)
• IoT systems with thousands of changing endpoints
• Diagnostics, temporary connections, fleet/rental equipment
• Exploring new data sources before committing to a tag model
• Systems where the external system governs the namespace (not your solution)

Configuration workflow:

1. Create a Discovery Services connection (UnsTagProviders table) with protocol and address
2. Optionally create an AssetTree folder linked to the connection
3. Access data using Asset() syntax — tags appear dynamically

Access syntax:

// In scripts or expressions:
value = Asset("/ProviderName/path/to/variable")

// In display element bindings (LinkedValue field):
Asset(Client.Context.AssetPath + "/Temperature")

// Static path in display bindings:
@Tag.ProviderName.path.to.variable

Key behavior:

• No local tags exist — data is accessed directly through the Discovery Services namespace
• The Asset() function takes a string that can be an expression (enabling dynamic UIs)
• Discovery Services auto-discovers the external tree structure at runtime
• Tags in the RTDB are created on-demand and cleaned up when no longer accessed
• Alarms and historian are NOT available on dynamic tags (no local tag to attach them to)

Modules involved: UNS (Discovery Services connection only). No tags, no devices.

Pattern Selection Guide

Most production systems use multiple patterns simultaneously. A typical split:

• ~30% Local Tags (safety, control loops, legacy PLCs)
• ~60% Linked Tags / DataLink (enterprise metrics, standard equipment)
• ~10% Dynamic Tags / Asset() (IoT fleet, diagnostics, dynamic sources)

Discovery Services Connections (UnsTagProviders Table)

Supported Protocols for Tag Discovery

Only protocols with built-in discovery capability can be used. The following connectors ship today (call list_protocols for the live list):

Important: The Device Module has ~100 protocols. Discovery Services has ~17. They are independent lists. Do not confuse them.

Historian Connectors — Dual Role

Some connectors (Canary, InfluxDB, GE Proficy, OSIsoft PI) serve two purposes:

1. Tag Discovery — browse and read historical data, TrendCharts auto-query through Asset() syntax
2. Storage Location — configured in Historian → Storage Locations as an archive target

When IsHistorian = true, TrendCharts using Asset() syntax automatically query the historian for time-range data.

Creating a Discovery Services Connection via MCP

get_table_schema('UnsTagProviders')
list_protocols('<protocol_name>')    // Get PrimaryStation format

Write example:

{
  "table_type": "UnsTagProviders",
  "data": [{
    "Name": "ProductionMQTT",
    "Protocol": "MQTT",
    "PrimaryStation": "localhost;1883;FrameworX-001;;;None;;AtLeastOnce;10",
    "Separators": "BranchSeparator=/;AttributeSeparator=/;",
    "Description": "Production floor MQTT broker"
  }]
}

Key fields:

• Name — becomes the root of the dynamic namespace: Tag.<Name>.*
• Protocol — must be one of the ~17 discovery-capable protocols
• PrimaryStation — protocol-specific connection string. Always call list_protocols() first to get the format.
• Separators — maps external hierarchy delimiters to UNS path delimiters. For MQTT: BranchSeparator=/;AttributeSeparator=/;

AssetTree Integration

The AssetTree makes Discovery Services data navigable in the UI. A linked folder connects an AssetTree node to a Discovery Services connection.

Creating Linked Folders via MCP

get_table_schema('UnsAssetTree')

{
  "table_type": "UnsAssetTree",
  "data": [{
    "Name": "Production/MQTTData",
    "TagProviderLink": "ProductionMQTT",
    "InitialBranch": "spBv1.0/GroupID",
    "Description": "MQTT production data linked to AssetTree"
  }]
}

From this folder down, the tree is dynamic — it auto-expands based on what the Discovery Services connection discovers at runtime.

When the user clicks a node in an AssetsTree control:

• Client.Context.AssetPath updates to the selected path
• Client.Context.AssetName updates to the selected node name
• All display elements bound to these properties react automatically

Asset() Syntax Reference

Basic Usage

// Read a value
double temp = TK.ToDouble(Asset("/ProviderName/path/to/temperature"));

// Write a value
Asset("/ProviderName/path/to/setpoint") = 75.0;

// Dynamic path from context (in display CodeBehind)
double val = TK.ToDouble(Asset(@Client.Context.AssetPath + "/Temperature"));

Data Type Handling

WPF (.NET Framework 4.8) — automatic type resolution works.

HTML5/Portable (NetStandard 2.0) — explicit conversion required:

int intValue    = TK.ToInt(Asset("/path"));
double dblValue = TK.ToDouble(Asset("/path"));
string strValue = TK.ToString(Asset("/path"));
bool boolValue  = TK.ToDigital(Asset("/path"));

Asset() vs Tag Syntax

Note: Asset() also works with local tags. It's sometimes used even with local tags because the string argument can be an expression, enabling dynamic display patterns.

Common Pitfalls

Mixed-Mode Example

A typical production solution combining all three patterns:

UNS Tags:
  Safety/EStop          ? Device Module (Modbus, deterministic polling)
  Safety/FireAlarm      ? Device Module (Modbus)
  Production/LineSpeed  ? DataLink: /MQTT/plant/line1/speed  (local tag + auto-comm)
  Production/OEE        ? DataLink: /MQTT/plant/line1/oee
  Quality/BatchResult   ? DataLink: /OPC/mes/quality/result

Discovery Services Connections:
  MQTT (ProductionMQTT) ? mqtt.factory.local:1883
  OPC  (MESServer)      ? opc.tcp://mes:4840

AssetTree:
  Plant/
    Safety/         ? manual tags, Device Module
    Production/     ? linked to ProductionMQTT via AssetTree folder
    Enterprise/     ? linked to MESServer, browsed via Asset() syntax

In this setup, safety tags have full deterministic control, production tags have local governance with auto-managed communication, and enterprise data flows dynamically with zero tag engineering.

See also

• Skill MQTT TagProvider. MQTT-specific Discovery Services implementation (broker connection, SparkplugB, built-in broker/simulator, UI construction).
• Skill MQTT Integration. Router for choosing between TagProvider and Device Module on MQTT brokers.
• TagProvider Services. Concept overview.
• UNS Tag Discovery Reference. Three connection patterns explained.
• UNS TagProvider Services Reference. All properties and settings.
• TagProvider Services Technology. Architecture deep dive.
• Unified Namespace. UNS foundation concepts.