Built-in Namespaces

Direct object model exposing all platform modules as .NET namespaces without API layers.

Platform → Technology → Supporting → Built-in Namespaces | Concept | Reference

Key Concepts 

Architectural Foundation

The built-in namespaces embody a unique architectural pattern: a one-to-three mirror system where the same object model reflects across:

• Designer UI - Module organization in configuration interface
• SQL Database - Table structure for configuration storage
• Git/DevOps - JSON export structure for version control

This triple mirror means learning one structure teaches you three - the UI navigation, the database schema, and the version control organization all follow the same namespace hierarchy.

Namespace Hierarchy

The platform organizes namespaces following the Four Pillars architecture:

UNS and the built-in namespaces are peers inside the Object Model — not sub-regions of UNS. UNS is strictly Pillar 1 (Data Foundation), the tag layer: Tag.*. The eleven built-in namespaces below — Server, Client, Alarm, Device, Historian, Dataset, Script, Report, Display, Security, Info — each sit alongside UNS as independent roots of the runtime Object Model. "The UNS" refers only to the Tag.* layer; "the Object Model" refers to the full 12-root hierarchy.

Object Model Power

All configured objects inherit from .NET classes, providing native functionality without custom coding. Unlike traditional systems requiring APIs or temporary variables, every object created in your solution immediately becomes a .NET object with full inheritance:

Built-in Intelligence Examples

csharp

DateTime Tag Operations

Tag.DateTimeExample.Value.DayOfWeek // Returns Monday, Tuesday, etc.
Tag.DateTimeExample.Value.AddDays(7) // Date arithmetic
Tag.DateTimeExample.Value.ToString("yyyy-MM-dd") // Formatting

Script Performance Monitoring:

Script.Task.Example1.LastCPUTime // CPU usage tracking
Script.Task.Example1.LastExecutionTime // Performance metrics
Script.Task.Example1.ExecutionCount // Execution statistics

Automatic Property Access

// Create an alarm group "ProductionAlerts" in Designer
// Immediately accessible at runtime:
Alarm.Group.ProductionAlerts.TotalCount      // Active alarm count
Alarm.Group.ProductionAlerts.UnackedCount    // Unacknowledged count
Alarm.Group.ProductionAlerts.Disable()       // Method to disable group

This means you get hundreds of methods and properties automatically - no coding required!

.NET Class Inheritance

// Tags are full .NET objects - use any .NET method:
Tag.StartDateTime.Value.DayOfYear           // .NET DateTime property
Tag.ProductName.Value.ToUpper()             // .NET String method
Tag.Temperature.Value.ToString("F2")        // .NET formatting

// Not programmed by FrameworX - inherited from .NET

.NET Namespaces Available:

• String manipulation (Substring, Replace, Trim)
• Mathematical operations (Min, Max, Round)
• Collection handling (Count, First, Last)
• Data conversion (ToInt32, ToDouble)

This means you get hundreds of methods and properties automatically - no coding required!

IntelliSense Navigation

The namespace structure enables full IntelliSense throughout the platform:

• Auto-completion in all configuration fields
• Type-safe property access
• Method signature hints
• Real-time validation

Context-Aware Syntax

Server-Client Domain Separation

Namespaces automatically handle distributed architecture:

Server Domain

• @Server.* - Global server properties
• Tag.* - Process values (synchronized)
• Alarm.* - System-wide alarms
• Device.* - Communication status

Client Domain

• @Client.* - Local client properties
• @Client.Username - Current user
• @Client.UI.CurrentPage- last display page open
• @Client.DateTimeInfo.Date- current date in the client computer

Even on a single computer, separate processes maintain this separation for security and performance.

Practical Examples

Display Navigation Control

// Direct display control without navigation APIs:
bool success = @Display.MainPage.Open();         // Open specific display
string current = @Client.DisplayName;            // Current display name
@Display.AlarmPanel.Close();                     // Close display

// Navigate based on conditions: 
if (@Tag.SystemMode.Value == 1) 
{
	@Display.ProductionView.Open();
}else
{
	@Display.MaintenanceView.Open();
}

Historian Runtime Access

// Access historian objects at runtime - no API needed:
int rowCount = @Historian.Table.ProcessData.RowCount;
DateTime lastStore = @Historian.Table.ProcessData.LastStoredTimeStamp;

// Query methods directly available: 
DataTable data = @Historian.Table.ProcessData.QueryData(startTime, endTime);

// Module control properties:
bool isRunning = @Historian.IsStarted; string status = @Historian.OpenStatusMessage;

Device Communication Status

// Direct access to device hierarchy:
bool channelActive = @Device.Channel.PLCChannel.IsActive;
int nodeCount = @Device.Channel.PLCChannel.NodeCount;
string status = @Device.Node.PLC1.Status;

// Access specific device points: 
double value = @Device.Node.PLC1.Point.Temperature.Value; 
int quality = @Device.Node.PLC1.Point.Temperature.Quality;

One-to-One Correspondence Benefits

Understanding namespace organization provides mastery across the platform:

External Access (10.1.5)

The same Object Model is accessible from outside the runtime process — no separate API layer is required. In 10.1.5 the platform exposes two equivalent surfaces over the existing 12 roots:

• Runtime REST API on TServer (port 3101+, Bearer-GUID): tag value reads/writes, GET /aggregates for historian summaries, alarm state, plus /health and /ready probes.
• RuntimeMCP tools: runtime_get_value, runtime_get_aggregated_history, runtime_get_active_alarms, runtime_browse_object_model, runtime_search_uns — the AI-facing surface against the same live Object Model.

Both surfaces traverse the same Tag.*, Alarm.*, Historian.*, Device.*, … roots as in-process scripts and Display bindings — external callers see the runtime state without going through a translation layer.

Performance Implications

Direct object access eliminates traditional overhead:

• No API serialization/deserialization
• No intermediate data structures
• Native .NET performance
• Compile-time optimization
• Type-safe execution

In this section...