Sorba AI Analytics Connector

MCP Tools server endpoint for compatible AI agents

Name: SorbaAI
Version: 1.0.0.0
Protocol: n/a
Interface: n/a
Runtime: .NET 2.0 (Multiplatform)
Configuration:
- UNS / TagProviders

Download SorbaAI solution template: SORBA.dbsln (version 10.1.5.2020)

Overview

The SorbaAI Tag Provider integrates FrameworX with the SORBA SDE industrial AI/ML platform. It enables FrameworX users to deploy and operate SORBA machine learning models — regression, classification, clustering, forecasting, digital-twin, and optimization — directly from the FrameworX Unified Namespace, with real-time data flow in both directions.

The driver implements the bidirectional MQTT protocol that SORBA uses to communicate with external gateways, exposing a SORBA model as a browseable tag namespace in FrameworX. Tag values flow continuously to SORBA for inference and training; SORBA pushes predictions, model-quality metrics, and anomaly indicators back into FrameworX as standard UNS tags.

Architecture

FrameworX UNS  <-->  SorbaAI Driver  <-->  MQTT Broker        <-->  SORBA SDE
       |                                  (Mosquitto / external)
       |
       +--->  FrameworX Historian Module (Canary / InfluxDB /
              FlowTimebaseDB / SQL — whichever the customer wired)

The MQTT broker is external to both products — typically the broker built into the SORBA SDE installation, but any MQTT 3.1.1 broker reachable from both ends works.
FrameworX publishes the model's structure, configuration, and live input values to the broker.
SORBA subscribes, trains the model, and publishes predictions / diagnostics back.
Each FrameworX deployment is identified to SORBA by a sanitized Instance ID, matching an Integration record on the SORBA SDE side.
When SORBA requests historical training data, the driver retrieves it via the FrameworX Historian Module — whichever StorageLocation backend the customer has wired serves the data. The driver itself stores no history on disk.

Prerequisites

FrameworX with the SorbaAI driver installed (ships with the product under ProtocolDriver/SorbaAIAdvanced).
SORBA SDE running and reachable on the network.
MQTT broker reachable from both ends:
- SORBA SDE's built-in Mosquitto (default port 1883), or
- The FrameworX built-in broker — see FrameworX MQTT Broker, or
- Any standalone MQTT 3.1.1 broker.
SORBA SDE Integration record matching the FrameworX Instance ID (see SORBA SDE-side setup).
Network access between FrameworX, the broker, and SORBA SDE.
For training: the FrameworX Runtime must be running (see Recommended Workflow), and the historian source tags must be configured with active historization in the FrameworX Historian Module.

Installation

The driver is included with FrameworX and registered as a protocol under Unified Namespace > Tag Provider Services. No separate install step.

To verify installation, in the FrameworX Designer, navigate to Unified Namespace > Tag Provider Services, click Add > Extension Module, and confirm SorbaAI Connector appears in the protocol list.

Setup

The setup has two halves that must match:

FrameworX side — add and configure a SorbaAI station.
SORBA SDE side — add an Integration record whose Name matches the station's Instance ID.

Both halves are required. Without the matching SORBA SDE record, SORBA ignores all MQTT traffic from this gateway.

SORBA SDE-side setup

In SORBA SDE's web UI, navigate to Edit Device → Services → Integrations. Add a new Integration with these values:

Field	Value to enter
Integration	`ExternalTool`
Name	Any name, it will be used later in FrameworX
Server Name	MQTT broker host (e.g. `localhost` if using SDE's built-in broker)
Port	MQTT broker port (default `1883`)
UserName	MQTT broker username
Password	MQTT broker password
Secure communication	Off (unless using TLS)
Server / Client Certificate, Client Key	PEM files for TLS, only if enabled

Save the record. SORBA SDE now listens for the topic prefix sorba_integration/<Instance ID>/... and will accept publishes from the FrameworX gateway.

FrameworX-side setup

In the Designer, open Unified Namespace > Tag Provider Services.
Click Add, choose SorbaAI as the protocol.
Configure the station fields (see the Station Configuration table below).
Open Unified Namespace > Asset Tree.
Link the newly created tag provider to a folder.
Save the solution.

When the station connects, it opens the MQTT connection and starts publishing the asset tree structure and live values to SORBA. The asset tree under the linked folder populates with the model's namespace (INPUTS/, OUTPUTS/, CONFIG/, etc.).

Station Configuration

The station is configured via a semicolon-separated string in the primary-station column. Fields are positional. Default values shown work out-of-the-box for a local SORBA SDE deployment with built-in broker.

#	Field	Type	Default	Description
1	Broker Host	string	`localhost`	Hostname or IP of the MQTT broker. Use `localhost` if SORBA SDE is running on the same machine as FrameworX.
2	Port	int	`1883`	MQTT broker port. Use `1883` for plaintext, `8883` for TLS.
3	Instance ID	string	`frameworx_gateway`	Tenant-like identifier for this FrameworX gateway. Sanitized to `a-zA-Z0-9_` and prepended with `sbr_` if empty, single-char, or starting with a digit. The result becomes part of every MQTT topic. Must match the Name in SORBA SDE's Integration record.
4	Algorithm	enum	`Regression`	The SORBA ML algorithm. Choices: `Regression`, `Classification`, `Clustering`, `Forecasting`, `DigitalTwin`, `Optimization`. Drives the shape of the asset tree (see Asset Tree Structure).
5	Model Name	string	`MODEL`	Display name of the model instance. Becomes the root of the asset tree (e.g. `MODEL/CONFIG/...`).
6	Username	string	empty	MQTT broker username. Leave empty for anonymous brokers.
7	Password	password	empty	MQTT broker password. Rendered as bullets in the editor; stored as `#<hex>` in the config string.
8	TLS CA PEM	string	empty	Path to the CA certificate PEM file. Only used when `Port=8883` or TLS is required.
9	TLS Client Cert PEM	string	empty	Path to the client certificate PEM file. Required for mutual TLS.
10	TLS Client Key PEM	string	empty	Path to the client private-key PEM file. Required for mutual TLS.
11	Output TTL Seconds	int	`30`	Time-to-live for dynamic `OUTPUTS` tags. If SORBA stops publishing a value for longer than this, the tag is automatically removed from the asset tree.
12	Reserved	string	empty	Reserved for future use. Previously `History Retention Hours`; no longer used now that historical data comes directly from the FrameworX Historian Module. Leave empty.
13	Input Sources	string	empty	Comma-separated FrameworX UNS tag paths (e.g. `Tag.Boiler1.Temperature,Tag.Pump.Flow,Tag.Machine.Speed`). Each becomes an input under `<Model Name>/INPUTS/` with a name derived from the source path (the `Tag.` prefix is stripped and dots are replaced by underscores — e.g. `Tag.Boiler1.Temperature` → `Boiler1_Temperature`). Values are read from FrameworX UNS every 1 second and forwarded to SORBA.

Example configurations

Scenario	Configuration string
Local SORBA SDE, 3 input tags	192.168.229.131;1883;FrameworX4;Optimization;opt4;admin;#2B22EF8FFF9EFF8CFF8CFF88FF90FF8DFF9BFF;;;;30;;Tag.Machine.Power,Tag.Machine.Current,Tag.Machine.Speed

Algorithm Selection

Each algorithm exposes a slightly different asset tree (specifically the TARGET/ folder). Pick the one matching your use case.

Algorithm	Use case	`TARGET/` folder
Regression	Predict a continuous variable from one or more inputs (e.g. predict Temperature from Pressure + Flow).	`response_variable` (`Text`)
Classification	Predict a discrete class from inputs (e.g. label as "normal" / "fault").	`response_variable` (`Text`)
Clustering	Group similar samples without labels (unsupervised).	(no TARGET folder)
Forecasting	Predict future values of a time series.	`response_variable` (`TextArray`) — plus `lag_steps`, `future_steps`, `window_length` under `CONFIG/TRAINING/`
DigitalTwin	Multi-output predictive model of a physical asset.	`response_variable` (`TextArray`)
Optimization	Recommend control-variable settings that minimize or maximize an objective.	`control_variables`, `independent_variables`, `optimization_goals`, `optimization_variables` (all `TextArray`)

ML UserTypes — algorithm categories vs. pre-loaded UDTs

Two different counts appear in SorbaAI material and they refer to different things:

6 algorithm categories — the driver-level Algorithm enum on the station, listed in the table above: Regression, Classification, Clustering, Forecasting, DigitalTwin, Optimization. This is the conceptual ML taxonomy the connector exposes.
Pre-loaded UserType definitions — concrete UDT shapes shipped inside the SORBA.dbsln template attached to this page. The template carries pre-loaded UserTypes for each algorithm variant and sub-type combination (for example, separate UDTs for the Regression model header, its inputs, its outputs, plus equivalents for Forecasting, DigitalTwin sub-shapes, and Optimization role variants).

The exact count of pre-loaded UserTypes varies by template configuration — see the SORBA.dbsln attachment for the authoritative list. The 6 algorithm categories above are the stable, driver-level concept; the UDT count is a template-side convenience and may evolve between template versions.

Asset Tree Structure

Once the station is connected and linked to an Asset Tree folder, the namespace appears under the configured Model Name root. Full layout for a Regression model named MODEL:

MODEL/
+-- CONFIG/
|   +-- RUNTIME/
|   |   +-- autolearning_status
|   |   +-- autolearning_time_range(min)
|   |   +-- autolearning_trigger
|   +-- TRAINING/
|       +-- DATASET/
|       |   +-- discard_nulls
|       |   +-- replace_with_last_value
|       |   +-- replace_with_value
|       +-- SYNTHETIC_TAGS/
|       +-- algorithm_type
|       +-- end_date
|       +-- history_storage_provider
|       +-- initialize_training
|       +-- output_message
|       +-- start_date
|       +-- time_zone
+-- INPUTS/             <- bound to FrameworX UNS source tags via "Input Sources"
+-- OUTPUTS/            <- SORBA pushes predictions here (dynamic)
+-- TARGET/
    +-- response_variable

CONFIG/RUNTIME/ — autolearning control

Controls SORBA's continuous autolearning loop.

Tag	Type	Default	Read/Write	Description
`autolearning_status`	`Text`	`Standby`	SORBA writes	Current autolearning state. Common values: `Standby`, `Training`, `Ready`, `Error`.
`autolearning_trigger`	`Digital`	`true`	User writes	When `true`, SORBA periodically re-trains the model using the most recent data window (see `autolearning_time_range(min)`).
`autolearning_time_range(min)`	`Integer`	`10`	User writes	Window size (in minutes) of historical data SORBA uses for each autolearning cycle.

CONFIG/TRAINING/ — explicit (manual) training control

For one-off manual training runs over a user-specified time window.

Tag	Type	Default	Read/Write	Description
`time_zone`	`Text`	`UTC`	User writes	IANA timezone identifier (e.g. `UTC`, `America/New_York`, `America/Sao_Paulo`). Tells SORBA the wall-clock of the gateway. Keep as `UTC` for predictable behavior — the driver auto-converts user-typed local times to UTC before publishing.
`algorithm_type`	`Text`	from station Algorithm	Seeded at Connect	Read-only echo of the Algorithm station setting (lowercased).
`output_message`	`Text`	empty	SORBA writes	Status / error messages from SORBA (e.g. "Training completed", "Target response variable was not found", "Model reg1 is already trained").
`initialize_training`	`Digital`	`false`	User writes	The manual training trigger. Set to `true` (after configuring the other fields) to instruct SORBA to start training. Published on the MQTT wire as a JSON boolean (`true` / `false`).
`start_date`	`DateTime`	empty	User writes	Start of the training window. Accepts the user's local clock time in multiple formats (see Date / Time Handling below). The driver auto-converts to UTC on the wire.
`end_date`	`DateTime`	empty	User writes	End of the training window. Same format flexibility as `start_date`. Must be at or before "now" for SORBA to start training (otherwise SORBA waits until `end_date` arrives).
`history_storage_provider`	`Text`	`default`	User writes	Reserved for future use. Keep as `default`.

CONFIG/TRAINING/DATASET/ — data preprocessing

How to handle bad / missing samples during training.

Tag	Type	Default	Read/Write	Description
`discard_nulls`	`Digital`	`false`	User writes	When `true`, samples with any null value are discarded during training. Mutually exclusive with the replace options.
`replace_with_last_value`	`Digital`	`false`	User writes	When `true`, null samples are replaced with the most recent good value of the same tag.
`replace_with_value`	`Float`	`0.0`	User writes	Numeric constant used to replace null samples when neither of the above options is set.

CONFIG/TRAINING/SYNTHETIC_TAGS/ — derived features

Not tested, contact Tatsoft Support if needed.

INPUTS/ — feature tags

Populated automatically from the Input Sources station-config field (P13). Each entry in the CSV becomes an input tag bound to a real FrameworX UNS tag:

Input Sources entry	Resulting INPUTS tag	Bound to
`Tag.Boiler1.Temperature`	`<Model Name>/INPUTS/Boiler1_Temperature`	FrameworX UNS tag `Tag.Boiler1.Temperature`
`Tag.Machine.Power`	`<Model Name>/INPUTS/Machine_Power`	FrameworX UNS tag `Tag.Machine.Power`

The driver reads each bound source via FrameworX's tag API at 1 Hz and forwards the value to SORBA on the same tick. The auto-derived input names (after stripping Tag. and replacing dots with underscores) are what you reference in TARGET/response_variable.

Why this matters: the response variable, synthetic-tag names, and optimization references must use the derived display names (e.g. Boiler1_Temperature), NOT the full source path (Tag.Boiler1.Temperature).

TARGET/ — what to predict

Contents vary by algorithm.

Regression / Classification:

Tag	Type	Default	Description
`response_variable`	`Text`	empty	Name of the input tag whose value SORBA predicts from the other inputs. E.g. `Machine_Power` (must match the leaf name under `INPUTS/`).

Forecasting / DigitalTwin:

Tag	Type	Default	Description
`response_variable`	`TextArray`	empty	List of input tag names to predict (multiple). E.g. `Temperature, Pressure`.

Optimization:

Tag	Type	Default	Description
`optimization_goals`	`TextArray`	empty	Optimization direction. Must be exactly one of: `minimum` or `maximum`.
`optimization_variables`	`TextArray`	empty	The variable(s) being optimized — what SORBA tries to minimize or maximize.
`control_variables`	`TextArray`	empty	Knobs SORBA is allowed to recommend changes to (manipulable variables).
`independent_variables`	`TextArray`	empty	Observed-only context variables — SORBA reads but does not adjust them.

Optimization role-exclusivity: each input tag must appear in at most one of optimization_variables, control_variables, independent_variables. SORBA rejects training if a tag appears in two roles.

Forecasting-specific extras (under CONFIG/TRAINING/):

Tag	Type	Default	Description
`lag_steps`	`Integer`	`6`	How many past samples to use as features for each prediction.
`future_steps`	`Integer`	`3`	How many steps ahead to predict.
`window_length`	`Integer`	`18`	Total length of the sliding analysis window.

OUTPUTS/ — predictions and diagnostics

Empty at startup. SORBA creates child tags dynamically as the model trains and starts producing predictions. The exact set varies by algorithm; for Regression you can expect (where <TargetName> is the value of TARGET/response_variable):

Tag	Type	Description
`<TargetName>_Prediction`	`Float`	SORBA's predicted value for the response variable.
`<TargetName>_Prediction_Error`	`Float`	Difference between predicted and observed value.
`<TargetName>_Prediction_Upper_Band`	`Float`	Upper bound of the confidence interval.
`<TargetName>_Prediction_Lower_Band`	`Float`	Lower bound of the confidence interval.
`<TargetName>_Prediction_Drift`	`Digital`	`true` if the prediction distribution has drifted from training; `false` otherwise.
`<TargetName>_Prediction_Drift_Score`	`Float`	Drift magnitude (0-1, higher = more drift).
`<TargetName>_Target_Drift`	`Digital`	`true` if the target variable's distribution has drifted; `false` otherwise.
`<TargetName>_Target_Drift_Score`	`Float`	Target drift magnitude.
`<InputName>_Tag_Ranking_Percent`	`Float`	How much this input contributes to the prediction (feature importance, 0-100).
`<InputName>_Tag_Ranking_p_value`	`Float`	Statistical significance of the contribution (0-1, lower = more significant).
`<InputName>_outlier`	`Digital`	`true` if this input is currently an outlier; `false` otherwise.
`<InputName>_Data_Drift`	`Digital`	`true` if this input's distribution has drifted; `false` otherwise.
`<InputName>_Data_Drift_Score`	`Float`	Per-input drift magnitude.
`Dataset_Drift`	`Digital`	`true` if the whole dataset has drifted; `false` otherwise.
`Best_Score_Training`	`Float`	Model quality score on training data (lower = better).
`Best_Score_Realtime`	`Float`	Same metric measured on live data.
`Model_Status_1_ok_2_error_3_warning`	`Integer`	`1` = OK, `2` = error, `3` = warning.
`Data_Status_1_ok_2x_error_3x_warning`	`Integer`	Same encoding for the data pipeline.
`Anomaly_Score_Percent`	`Float`	Current anomaly score (0-100, higher = more anomalous).
`Anomaly_Detection_Analog`	`Float`	Analog anomaly signal.
`Anomaly_Detection_Boolean`	`Digital`	`true` if currently anomalous; `false` otherwise.
`Anomaly_Detection_High_Limit_Threshold`	`Float`	Upper threshold above which the boolean trips.
`Anomaly_Detection_Low_Limit_Threshold`	`Float`	Lower threshold below which the boolean trips.
`Anomaly_Detection_Notification_Warning`	`Digital`	Warning-level notification flag.
`Anomaly_Detection_Notification_Critical`	`Digital`	Critical-level notification flag.

Top three outputs to watch for Regression: <TargetName>_Prediction (the actual answer), <TargetName>_Prediction_Error (how wrong it is right now), and Model_Status_1_ok_2_error_3_warning (model-health gate). Visualize the prediction with the Upper / Lower Band pair as a confidence-interval shaded chart.

Outputs are dynamic. If SORBA stops publishing a particular output for longer than the Output TTL Seconds value (default 30s), the tag is automatically removed from the asset tree. This keeps stale predictions from lingering forever when a model is undeployed.

Date / Time Handling

The start_date and end_date fields under CONFIG/TRAINING/ are DateTime-typed and accept the user's local clock time. The driver auto-converts to UTC before publishing to SORBA on the MQTT wire — keeping the gateway's declared time_zone="UTC" consistent end-to-end.

Concrete example — operator in São Paulo (UTC-3) types 15/05/2026 16:30:00.000 into start_date:

Where	Value seen
FrameworX Asset Tree display	`5/15/2026 4:30 PM` (local clock, format depends on FrameworX locale)
MQTT wire payload (Phase B)	`"value": "May 15, 2026, 7:30:00 PM"` (UTC equivalent of 16:30 SP, in SORBA's en-US envelope format)
SORBA's training window	Lines up correctly because SORBA interprets the timestamp under the gateway's `time_zone="UTC"` declaration

Accepted input formats (all interpreted as local-clock time):

Format	Example
`dd/MM/yyyy HH:mm:ss.fff`	`15/05/2026 16:30:00.000`
`dd/MM/yyyy HH:mm:ss`	`15/05/2026 16:30:00`
`dd/MM/yyyy HH:mm`	`15/05/2026 16:30`
`dd/MM/yyyy`	`15/05/2026`
With timezone offset	`15/05/2026 16:30:00 -03:00`
ISO-like	`2026-05-15 16:30:00.000`, `2026-05-15T16:30:00`
SORBA's en-US envelope	`May 15, 2026, 4:30:00 PM`

Format-with-offset variants (... -03:00) honor the embedded offset. Format-without-offset variants are assumed to be the operator's system-local time. Either way, the driver publishes UTC on the wire.

Triggering Training

Two paths to start SORBA training a model:

Manual training (one-off run)

Set the TARGET/ fields, the training-window fields, then flip the trigger. SORBA reads, requests historical data, trains, and starts pushing predictions.

Set TARGET/response_variable (or the equivalent for your algorithm). Example: Machine_Power.
Set CONFIG/TRAINING/start_date to the start of your training window (local time — see Date / Time Handling).
Set CONFIG/TRAINING/end_date to the end of the window (must be at or before "now").
Set CONFIG/TRAINING/initialize_training to true.

Within a few seconds, CONFIG/TRAINING/output_message will reflect SORBA's response:

Training started / Training completed — success.
Target response variable "..." was not found — the response_variable name doesn't match any INPUTS child.
Training start date is not in the correct format — date string couldn't be parsed.
No data found for training — the FrameworX Historian Module returned no samples for the requested window. Verify that the input source tags have active historization in the Historian Module.
Collecting data — N time remaining — end_date is in the future; SORBA is waiting.
Model <name> is already trained — model exists and is current.

Autolearning (continuous)

Once configured (response_variable set, etc.), set CONFIG/RUNTIME/autolearning_trigger to true and SORBA will periodically re-train using the most recent autolearning_time_range(min) minutes of data. autolearning_status reflects the cycle state (Standby → Training → Ready).

Recommended Workflow — Operate from the Runtime

Strong recommendation: trigger training and consume predictions while operating from the FrameworX Runtime, not from the Designer. The Runtime must be running anyway — historical data retrieval depends on it.

Why: when SORBA requests training data, the driver calls back into FrameworX's Historian Module to read the training window's samples. This callback is only wired in the Runtime process, not in the Designer alone. Without the Runtime up, historical responses come back empty and SORBA cannot train.

Single rule to remember: the last application opened — Designer or Runtime — is the one that ends up connected to SORBA. If you train from the Designer while the Runtime is running, both must be restarted to recover from the Designer's stale read-cache.

If you must use the Designer (e.g. for ad-hoc experimentation):

Expect output_message to lag or stay on a previous run's status.
Recovery: close Designer → reopen → reconnect the SorbaAI station → restart Runtime. The next update from SORBA then refreshes output_message and the other status fields immediately.

Symptom-side this looks like training "hanging" or output_message showing stale text even though SORBA clearly published a fresh update to the MQTT broker. Underlying cause is the Designer's read-cache going stale during a prolonged session.

Observing Traffic — Use an MQTT Payload Viewer

For both diagnosis and during normal operation, we recommend keeping an MQTT payload viewer open against the same broker the SorbaAI station is connected to. Recommended tools:

MQTT Explorer — free, cross-platform, tree-view UI.
mosquitto_sub -t '#' -v — command-line, ships with Mosquitto.

Subscribe to the wildcard sorba_integration/<instanceId>/# and you'll see the full conversation between FrameworX and SORBA flowing in real time:

Outbound (gateway → SORBA)
- tags/structures (every 10 s)
- tags/inputs/realtime (every 1 s)
- tags/inputs/historical (Phase E batches during training)
- udt_definitions
Inbound (SORBA → gateway)
- tags/outputs/realtime (live model predictions)
- tags/outputs/structure (the OUTPUTS schema SORBA announces)
- tags/inputs/historical/request (SORBA asking for a training window)

Why this matters: when SORBA sends a status update via output_message, you'll see it on the broker instantly in the viewer — even if it's lagging in Designer's Asset Tree (per Recommended Workflow). That distinguishes "SORBA is silent" from "SORBA responded but the Designer hasn't refreshed yet" — two completely different problems with different fixes.

Historical Data

When SORBA requests historical samples to train a model, the driver retrieves them from FrameworX's Historian Module — whichever StorageLocation backend the customer has wired (Canary, InfluxDB, FlowTimebaseDB, SQL, …). The driver is backend-agnostic.

Implications:

Each source tag referenced in Input Sources must have active historization in the FrameworX Historian Module to produce training data.
Training windows can cover any period the historian has data for, including long ranges (days, weeks, months) — limited only by historian retention.
No on-disk persistence inside the driver itself; nothing is duplicated.
If a source tag isn't historized, SORBA's historical request returns empty and output_message reports No data found for training.

Multi-station Deployments

Multiple SorbaAI stations can coexist in a single FrameworX solution, each managing its own SORBA model independently.

Per-station setting	Should differ between stations?
Broker Host / Port	May be the same (one broker) or different (multiple brokers)
Instance ID	Must be unique per station — drives the MQTT topic namespace
Model Name	Must be unique per station — drives the asset tree root
Algorithm	Independent — different algorithms per station OK

Each station needs its own matching Integration record on the SORBA SDE side with the same Instance ID.

Troubleshooting

Symptom	Likely cause	Fix
Station fails to connect; trace shows "broker not reachable"	Wrong Broker Host / Port; broker not running; firewall blocking	Verify broker host:port; ping the broker host; test broker with `mosquitto_sub` from the FrameworX machine.
Station connects but SORBA never responds	No matching Integration record in SORBA SDE	Add Integration in SORBA SDE with Name equal to the station's Instance ID.
`output_message` = "Target response variable ... not found"	`TARGET/response_variable` is empty or doesn't match any `INPUTS/` child	Set `response_variable` to a valid input name. Names must match the derived (Tag.-stripped, dots-replaced) form, e.g. `Boiler1_Temperature`, not `Tag.Boiler1.Temperature`.
`output_message` = "Training start date is not in the correct format"	Date string is malformed	See Date / Time Handling for accepted formats. The most reliable is `dd/MM/yyyy HH:mm:ss.fff`.
`output_message` = "No data found for training"	The FrameworX Historian Module has no samples for one or more bound source tags in the requested window	Confirm each source tag in Input Sources has active historization configured in the Historian Module, and that the window overlaps a period the historian was active.
OUTPUTS folder is empty after training	SORBA hasn't pushed predictions yet (training in progress) or model failed	Wait a few seconds; check `output_message` for error; verify with an MQTT payload viewer that SORBA is publishing on `sorba_integration/<instanceId>/tags/outputs/realtime`.
Outputs appear briefly then disappear after ~30s	TTL eviction (SORBA stopped publishing)	Increase Output TTL Seconds or investigate why SORBA stopped publishing.
`TK.Asset("/<alias>/<Model>/OUTPUTS/...")` returns empty in Runtime	Tag isn't yet subscribed by any client (Display / Script / external)	Add the tag to a Display, reference it in a Script, or wire to an Alarm — that triggers host-side registration. After first subscription, live values flow.
Designer's `output_message` stays stale even though SORBA published an update	Designer's tag-resolution cache went stale	Close Designer → reopen → reconnect station → restart Runtime. See Recommended Workflow.
No traces visible in FrameworX's Trace window	Host trace pipeline silent for the SorbaAI extension-module driver	The driver writes a complete diagnostic trace to the file `C:\Temp\SorbaAI_Trace.log` regardless of the host trace pipeline. Inspect that file for every event (`Write`, `PhaseC`, `FrameworxHistorian`, etc.).
Failed To Register Asset errors for `<Model>/CONFIG/TRAINING` or `CONFIG/RUNTIME` (older builds)	Intermediate folder paths weren't pre-registered	Fixed in current version — driver now registers all intermediate folder placeholders at Connect.

Document version: 2026-05-18 — reflects current SorbaAI driver behavior including FrameworX-Historian-backed history, Input Sources (real tag bindings), multi-format DateTime parsing with UTC auto-conversion, MQTT viewer recommendation, and the file-based trace fallback.

In this section...

Page tree