# Welcome This is the official documentation site for Tricloud Nexus. Explore our comprehensive resources to help you connect, query, and analyze your data with ease. Whether you're a new user looking to get started or an experienced professional seeking advanced insights, we’ve got you covered. Let’s get started! Use the navigation menu to the left to find the resources you need or search for specific topics above.
# Overview of Tricloud Nexus Tricloud Nexus is an Industrial IoT (IIoT) platform designed to help businesses connect technical systems with cloud-based tools. It enables organizations to manage, analyze, and improve their operations efficiently, by simplifying data collection and management. The platform is modular and scalable, making it suitable for a variety of industries and use cases. ## Nexus Features Tricloud Nexus is built around three key areas: **Applications**, **Operations**, and **Insights**. Together, these features make it easier to collect data, manage systems, and use insights to improve business performance.

Nexus Features

### Applications Tricloud Nexus ensure businesses have the required tools to design solutions, that collect the right data and work smoothly with existing infrastructure. It simplifies the creation, customization, and integration of Industrial IoT (IIoT) solutions to meet specific business needs: * **Design Data Collection:**\ The platform makes it easy to set up and configure data collection from a wide variety of assets. It supports industry-standard protocols such as OPC-UA, MQTT, and ModBus, ensuring compatibility with most technical systems. This flexibility allows businesses to integrate legacy equipment alongside modern devices. * **Build Modules and Applications:**\ Nexus Edge software enables the development of custom modules or containers in languages like Python or C#. These modules allow businesses to add specific functionality or workflows, enabling them to tailor the platform to their operational requirements. * **Integrate with Other Systems:**\ Tricloud Nexus seamlessly integrates with many third-party tools like PowerBI, Grafana, or Microsoft Fabric. These integrations expand the platform’s functionality, offering advanced reporting, data visualization, and analytics capabilities. ### Operations Tricloud Nexus provides the necessary tools to manage and maintain IIoT systems effectively. The features focus on managing and maintaining the devices and systems connected to the platform. These tools ensure reliable performance and help reduce downtime: * **Manage Devices:**\ Tricloud Nexus provides a central Management Portal for configuring and controlling devices. Users can remotely update settings, deploy new software, and monitor device health, making it easier to maintain a fleet of devices across different locations. * **Maintain System:**\ The platform includes tools for proactive system maintenance. This includes 24/7 monitoring of installations, secure updates, and built-in support for troubleshooting potential issues remotely. These features help businesses avoid disruptions and keep operations running smoothly. * **Monitor Solutions:**\ Real-time monitoring features allow users to track system performance and detect anomalies as they occur. Integration with Azure IoT Hub ensures robust and secure communication between devices and the cloud, providing reliable data streams and alerts. ### Insights Tricloud Nexus is designed to help businesses make sense of the collected data, by turning the raw data into practical insights. By organizing and analyzing information, the platform supports informed decision-making and continuous improvement: * **Visualize Data:**\ The platform includes tools for creating intuitive dashboards and reports, powered by platforms like Azure Data Explorer (ADX). These tools help users track key metrics, identify trends, and gain a clear understanding of their systems’ performance over time. * **Analyze Information:**\ Built-in analytics capabilities allow businesses to identify inefficiencies, spot patterns, and understand the root causes of issues. This helps organizations respond quickly to operational challenges and optimize processes. * **Improve Business:**\ Insights derived from Tricloud Nexus enable organizations to implement meaningful changes, whether it’s streamlining workflows, reducing costs, or enhancing system reliability. # Purpose and Scope of the Documentation The purpose of this documentation is to provide users with the knowledge and tools required to effectively use the Tricloud Nexus platform. It is designed as a comprehensive resource, offering step-by-step instructions, detailed explanations, and answers to frequently asked questions to ensure users can fully utilize the platform’s features and functionality. The documentation is structured to serve as an online reference for customers, whether they are just starting with the platform or looking to explore advanced features. It includes: **Quick Start Guides**\ Step-by-step guides to help users set up and begin using Tricloud Nexus quickly and efficiently. These guides cover essential tasks such as onboarding devices, configuring the platform, and visualizing data. **Platform Architecture**\ This documentation ensures that users have a clear understanding of the platform’s architecture and how to leverage it effectively in their operations. * **High-level Overview**\ An introduction to the overall structure and design of the Tricloud Nexus platform. This section explains how the different components work together to provide a seamless and scalable IoT solution * **Security Architecture**\ A comprehensive explanation of the platform’s security framework. This section details how Tricloud Nexus ensures the safety of data, devices, and communications. Topics include encryption, authentication methods, secure deployment practices, and compliance with relevant standards * **Platform Integration**\ This section covers the various ways users can integrate with the Tricloud Nexus platform. It provides detailed guidance on: * **APIs:**\ A complete reference for the Nexus REST API, including endpoints, authentication methods, usage examples and integration guides for connecting Tricloud Nexus with other systems. This section supports developers who want to build custom applications or extend platform functionality. * **Command-Line Interface (CLI):**\ Instructions for using the Nexus CLI for task automation, system management, and other advanced operations. This includes command syntax, use cases, and examples. **Management Portal**\ The Management Portal serves as the primary interface for controlling and overseeing IoT systems. A thorough explanation of the Management Portal features and functionality is available. This includes guidance on managing devices, monitoring performance, maintaining systems, and integrating with external tools and services. **Edge**\ This section covers all aspects of edge device capabilities within the Tricloud Nexus platform. It includes a detailed explanation of how Nexus integrates with edge devices, and the functionality running at the edge. * **Nexus Modules**\ A catalog of pre-built modules delivered with the Nexus platform. Each module is described with its functionality, setup process, and examples of usage. These modules allow users to handle tasks like protocol translation, data aggregation, and device-specific operations without requiring custom development. * **Edge SDK**\ Documentation for the C# and Python SDKs, enabling users to create custom modules for their specific use cases. This section includes setup guides, examples, and best practices for module development. It also covers how to deploy and manage custom modules on edge devices. # Release Notes # 2025-02-14 - Release 2.0 ## Highlights * Comprehensive Online Documentation for Tricloud Nexus is now available. ## New Features * Added new Historian Data Connector that acts as a Sink for Measurements at the Edge * Improved Monitoring new Data Collector Status overview\... * Improved Monitoring new logging features..... * And many more... ## Fixes * Many smaller bug fixes.... * * And many more... ## Breaking Changes * None ## Security Updates * Upgraded Tricloud Nexus API and Management Portal to .NET 9 # 2024-12-20 - Release 1.8 ## Highlights * **Initial support for Unified Namespace:** Tricloud Nexus now supports collecting data from a MQTT Broker and write the measurement to other Data connectors. It also supports writing measurements from any Tag to an MQTT Topic. * **Introduction of Update Center:** Tricloud Nexus now features a new Update Center that allows easy management of both Module and Application updates across all devices in your fleet * **Scheduled Deployments:** Deployments of Device Configurations can now be scheduled to run at a predefined date-time from both Device Configuration, Deployments and Update Center * **Improved Usability in Tag Configuration:** Configuration of Tags now got a lot easier with a new and improved UI for easy configuration of Tags, Sampling rates, Access, storage etc. * **Added new Tag Editors:** Increased usability by adding several new Editors to customize Tag settings including ModBus- & Formula Editor * **Import public containers:** Added ability to import containers from public available docker registries, configure settings for the container and deploy them to devices ## New Features * Added MQTT Read/Write support, making it possible to write any Tag to a MQTT Connector publish Topic * Added Update Center that allows updates of Modules or Applications to be performed immediately or scheduled across all devices in a single operation * Introduced UI for viewing and re-scheduling deployments in the management portal * Added new UI to support import and configuration of 3rd party containers from public docker repositories * Added Formula Editor that lets you easily specify advanced operations on the measurements using Tags as references * Added ModBus Editor to improve usability when configuring Tags for a ModBus connector * Improved Monitoring adding ability to see metrics from each running Module on the Information Tab of the Module * Hierarchy validation now supports less restrictive naming rules for data connectors * Management Portal now loads the last selected hierarchy when opening Asset modelling * Added support for Debian 12 in Edge compatibility * And many more... ## Fixes * Deployment is no longer possible if the Device Configuration contains an Application that no longer exist * Fixed delayed synchronization of asset hierarchy to ADX during initial deployments * Resolved errors related to Modbus read address validation * Fixed deployment scheduling issues, including incorrect or missing scheduled deployments * Addressed multiple UI inconsistencies, such as button placements and tooltip visibility * Resolved issues with duplicate modules and outdated deployment logs in monitoring views * And many more... ## Breaking Changes * Removed support for legacy Asset Hierarchy naming convention based on only Asset.Tag naming. ISA95 naming convention is now the future standard ## Security Updates * Updated IoT Edge Runtime 1.5.15 LTS * Upgraded Tricloud Nexus Edge Modules to .NET 8 * Upgraded CLI Tool to .NET 8 # 2024-10-05 - Release 1.7 ## Highlights * **Enhanced File Transfer Module:** Added support for SFTP servers and SMB fileshares, with the ability to monitor jobs and browse file systems through Edge Devices. * **Improved Device Configuration:** Introduced new Overview and Settings tabs, hierarchy selection wizard, and versioning for device configurations. * **Application Enhancements:** Applications now feature an Information tab for key property management, deployment statistics, and versioning similar to asset hierarchies. * **MQTT Connector Upgrades:** Added publish topic type, QoS settings, message retention, and timestamp conversion from local time to UTC using JSONata. * **UI and Usability Improvements:** New tooltips, filters for device lists, and improved help for missing monitoring metrics increase usability across the Management Portal. ## New Features * Added support for SFTP Servers in FileTransfer Module * Added support for SMB Fileshares in FileTransfer Module * Added ability to Monitor Jobs in FileTransfer Module using Jobs History tab * Added ability to Browse FTP/SFTP Servers or FileShares through an Edge Device in FileTransfer Module using Browse tab * Added new Overview tab of a Device in Device Configuration to summarize important information * Added UI in Device Configuration for displaying all configured tags of an added Asset Hierarchy * Device Configuration Versioning now works the same way as Asset Hierarchies * Added new Settings Tab in Device Configuration to enable configuration of Ingestion Endpoint and Provisioning of a new Edge Device * Added Hierarchy selection Wizard in Device Configuration * Added Information tab to an Application, that allows modifying key properties of an Application, eg. logo, description and deployment statistics * Added UI in Applications to for showing all devices that application has been deployed to * Application Versioning now works the same way as Asset Hierarchies * Added Filter in Device List of the Device Configurations * Added many new Tooltips to increase usability of the Management Portal * Added Publish Topic type for the MQTT Connector * Added ability to set the Quality Of Service (QoS), and Retain Messages on the MQTT Connector * Added ability to convert MQTT Payload timestamp from local time to UTC using the JSONata editor * Added a Link from Deployment to the deployed Device configuration * Added UI Help when Missing monitoring metrics on a Device in Monitoring * And many more... ## Fixes * Management Portal now properly remembers selected node in hierarchy selection * Fixed that in some rare occasions, it was possible to leave the AssetModelling Page without getting warned by unsaved changes * Device Configuration - OverView Tab. Cannot properly edit text in the description text area * Fixed that Import Asset Hierarchy crashed in some rare occasions * Fixed that it is now possible to Import an Asset Hierarchy, even if no Asset Hierarchies are present in the Environment * Applications + Modules - Updating Create Options removes DesiredTwin and vice versa. * Fixed error in Management Portal when viewing applications in empty platform * Fixed: Unable to restart edgeAgent/edgeHub from monitoring * Device Configuration settings: gateway spelling error corrected * Hierarchy Comment is out of screen * Delete button not placed correctly. * Align Label AssetHierarchy to look like other Labels * And many more... ## Breaking Changes * No Breaking Changes in this release ## Security Updates * Updated IoT Edge Runtime 1.5.10 LTS * Upgraded Telerik UI for Blazor to version 6.2.0 # 2024-07-01 - Release 1.6 ## Highlights * **Enhanced Hierarchy Management:** View and manage hierarchy details, including datastore updates for all measurements in a hierarchy * **MQTT Connector with Transformation:** Introduced a new MQTT connector with real-time payload transformation using JSONata * **Pre-Configured Module Store:** Includes third-party container images like InfluxDB, Redis, PostgreSQL, Grafana, and NodeRED * **Improved Monitoring and Device Management:** Enhanced metrics for OS, disks, memory, and CPU, along with better device management tools * **Simplified Device Provisioning:** UI-guided installation for Edge Devices and added support for Red Hat Enterprise Linux ## New Features * Hierarchy Root Node now shows Hierarchy Details and lets you change Datastore for all measurements collected for the hierarchy * Enhanced Support for ISA-95 tag naming convention in platform * Asset Hierarchy Nodes can now be ordered using drag'n'drop * New MQTT Connector now available * Added ability to transformation MQTT Payloads from MQTT Connector on the fly using an Editor for MQTT Read Tags based on [JSONata](https://docs.jsonata.org/overview.html) (a lightweight query and transformation language for JSON data) * Improved performance of backend resources * Added UI to manage Device Ingestion Endpoints in platform settings * Added UI to manage Device Management Endpoints in platform settings * Added UI to manage Device Provisioning Endpoint in platform settings * Tricloud Nexus now comes with 3rd party container images pre-configured as Modules in Module Store: InfluxDb, Redis Cache, SQL Server, PostgreSQL, Mosquitto MQTT Broker, Grafana and NodeRED. * Device Provisioning Scripts are publicly available for download by any platform instance * Added UI-guided installation of new Edge Devices * Added Provisioning support for Red Hat Enterprise Linux * Added Mount Module that enables configuration to be managed for other 3rd party Modules * UI enhancements for Time Series Explorer including better filtering of Tags * Module Store now lets you edit module settings for each Module Version * Added Validation step in Device Configuration that prevents accidently deploying an Asset Hierarchy that is not validated * Added functionality to Export and Import Asset Hierarchies of a specific version * Improved Monitoring and Device Configuration by adding better metrics and information about OS, Disks, Memory and CPU * Added ability to remove a Device from the Management Portal * And many more... ## Fixes * Fixed that Module logs with special characters could cause a 500 internal server error * Fixed that you were unable to delete device management endpoint with a device that had no deployments * Fixed Device Connection State which was not always up to date * Fixed minor issues that would prevent editing asset hierarchies * And many more... ## Breaking Changes * Removed IoT Edge provisioning support for RHEL 7 and Debian 10 (Support deprecated by Microsoft) ## Security Updates * Upgraded Management Portal to .NET 8 * Updated IoT Edge Runtime 1.5.4 LTS * Upgraded Telerik UI for Blazor to version 6.0.0 * Update Blazor ApplicationInsights to V3 # 2024-02-25 - Release 1.5 ## Highlights * Designed new look'n'feel for the entire Management Portal of Tricloud Nexus * Performance enhancements in Azure Data Explorer by introducing Partitioning in tables * New materialized views created in database that pre-aggregates measurements and introduces enhanced features such as Avg, Min, Max StdDev * Minor fixes in Edge modules and Applications * Major performance improvement in Nexus API after upgrade to .NET 8 ## New Features * The UI of Management Portal is completely redesigned to a more user friendly and modern design * Whitelabelling of the Management Portal can be customized in Platform Settings * Fonts used in platform UI now has smaller size * DeviceRegistration now has gateway and parent device properties * Partitioning, HotCache, and Materialized Views with enhanced features for measurements * CLI can create pre-defined application templates ## Fixes * Streaming measurements not working (updated DM schema) * Bugs in application templates * OPC-UA Client could not read config in certain circumstances * Empty field in Create Hierarchy name generated an error message * Direct deployments hangs, if a module has no Desired Twin and the Deployment is being done to an offline-device ## Breaking Changes * No breaking changes in this release ## Security Updates * Upgraded Nexus API to .NET 8 * Updated IoT Edge Runtime 1.4.3 LTS #### # 2023-10-09 - Release 1.4 ## Highlights * Enhanced asset hierarchy validation with new API endpoints. * Simplified Web Portal UI and improved module management functionality. * Various fixes and updates to backend services, web portal, and PowerShell scripts. ## New Features * Added global create options override for modules via file blobs stored in the device storage account. * Asset Hierarchy validation APIs now validate both saved hierarchies and unsaved changes, providing detailed error information. * Search functionality added to asset hierarchies and explorer asset hierarchies in the Web Portal. * Simplified Web Portal UI by removing redundant elements and improving navigation. ## Fixes * Resolved issues with Asset Hierarchy updates and FTP Data Source password handling. * Fixed datastore CRUD operations, ensuring correct ID handling after creation. * Parameters now correctly update when importing new versions of existing modules. * Fixed page scrolling and deep-link navigation for device profiles in the Web Portal. * Resolved mapper and nullability issues in Jobs functionality. * Removed errors when opening links in new tabs using custom JavaScript. * Fixed PowerShell script issues for Telerik upgrades. ## Breaking Changes * Removed certificate authentication method from OPC UA for improved consistency and alignment with current functionality. ## Security Updates * Updated third-party dependencies (NuGet packages) for enhanced security and performance. #### # 2023-05-09 - Release 1.3.1 ## Highlights * This release is a hotfix to fix a bug when saving an asset hierarchy in a new revision. ## New Features * No new features in this release. ## Fixes * Fix: Fixed an issue in api where saving hierarchy changes results in incorrect mapping of areas and assets in the asset hierarchy revision, leading to inconsistencies in the revision history. ## Breaking Changes * No Breaking changes in the release. ## Security Updates * No security updates in this release. #### # 2023-04-28 - Release 1.3 ## Highlights * Major updates to platform components, enhancing performance, security, and modularity. * Introduced support for managed identities across services and components. * New features in API, web portal, and infrastructure for improved usability and scalability. * Breaking changes in deployment methods and module configurations. ## New Features * Support for multiple-IoT Hubs and multi-storage account provisioning. * Enhanced UI for module management and data source configuration. * Support for visualizing string and digital measurements in Explorer Hierarchy. * Improved asset hierarchy management introducing revisions at root node. * Redeploy button for quick rollback of previous deployments. * Support for managed identities in ingestion and log handling. * Enhanced module and hierarchy deployment capabilities, including support for multi-architecture Docker manifests. * OAuth implicit security schema added. * App insights API key management integrated into ARM deployment. * Refactored IoT Hub templates to enhance flexibility and resource group support. ## Fixes * Addressed various deployment, logging, and ingestion bugs across modules. * Improved reliability of hierarchy snapshots and tag naming conventions. * Resolved UI and backend errors in the web portal and Explorer Hierarchy. * Fixed issues in module start-up sequences and device configurations. ## Breaking Changes * Ingestion log handling now requires managed identity and Event Grid configuration. * Deployment manifest generation switched from JSON templates to code-based configuration. * SignalR upstream updates moved to bicep template applied post-deployment. * Container registry tag renamed from `Tag` to `ImageTag`. ## Security Updates * Updated third-party dependencies and Azure SDKs for improved security and performance. * Added explicit ingestion batching policies for hot path tables with low-latency batch ingestion. #### # 2023-02-14 - Release 1.2 ## Highlights * Introduction of semantic versioning using GitVersion. * Enhanced schema support for hierarchy snapshots and ISA95 naming conventions. * Major updates to Azure templates with full conversion to Bicep. ## New Features * Automatic versioning with GitVersion and semantic versioning. * PowerShell script (`Register-DataStores.ps1`) for streamlined data store registration. * New dimension tables for hierarchy snapshots and metadata (AssetHierarchyRevisions and AssetHierarchyMetadata). * Full schema support for ISA95 naming convention with hierarchical names on all tags. * Materialized views for the latest snapshot of asset hierarchy and metadata. * All Azure Resource Manager (ARM) templates converted to Bicep for better maintainability. ## Fixes * Backend app now granted the Viewer database role instead of UnrestrictedViewer. * Improved data connection template dynamically resolves resource IDs for hot and cold path resources. ## Breaking Changes * No breaking changes in this release. ## Security Updates * No security updates in this release. ## # Quick Start Guide Welcome to the Tricloud Nexus IoT Platform. This guide is designed to help you quickly set up data collection using an edge device and demonstrate how to gain valuable insights from the collected data. Through this guide, you will learn how to provision an edge device, set up and deploy an Asset Hierarchy to define the data to be collected, and explore the platform's capabilities using emulated data. By the end of this guide, you'll have a solid foundation to leverage the platform effectively for your IoT projects. # Provision an Edge device Before configuring data collection or deploying modules and application you need to provision an edge device. This quick-start will guide you through provisioning of an edge device. ## Edge Devices An edge device in Tricloud Nexus is based on [Azure IoT Edge](https://github.com/Azure/azure-iotedge), which supports a range of OS options. To learn more about the [capabilities](https://learn.microsoft.com/en-us/azure/iot-edge/about-iot-edge) and [supported systems](https://learn.microsoft.com/en-us/azure/iot-edge/support), see the [official documentation](https://learn.microsoft.com/en-us/azure/iot-edge/). *** ## Setup an Edge Device Follow these instructions to create and connect an Edge device to Tricloud Nexus. ### Prerequisites Before provisioning an edge device and connecting it to Tricloud Nexus, you must first install a [supported OS](https://learn.microsoft.com/en-us/azure/iot-edge/support#operating-systems) on the target computer. You must also ensure that the target computer has outbound network connectivity to a set of pre-defined hostnames, which is used during provisioning and for data collection. See this [list of hostnames](#hostname-allow-list) used by edge devices. ### Create a device configuration To provision a device in Tricloud Nexus, the first thing to do is to create a configuration for the device. 1. First select **Configurations** under the **Management** section in the navigation menu. 2. Then click **Add** in the **Devices** toolbar. 3. In the **New Device Configuration** dialog enter a unique device id (*NOTE: a device id can only contain the characters A-Z, a-z, 0-9, -, \_*) and then click **Save**. 4. The device configuration will appear under the **Unprovisioned** device list ### Provision the device Once the device configuration has been created, the next step is to provision the device and connect it to Tricloud Nexus. 1. Go to **Settings** under the newly created device configuration. 2. Select **Provision Device**. 3. In the **Provision a Device** dialog, first select the device OS (*Linux or Windows*) and then select the variant and version. 4. Then select a Provisioning Endpoint, which in most scenarios is already pre-selected and then select an Enrollment option, which this quick-start guide assumes is set to *Symmetric Key* attestation mechanism. 5. Then follow the on-screen instructions for: 1. Prerequisites: login and download of the device installation script 2. Installation: Runs the installation and provisioning script 3. Verification: Steps to ensure that the device is provisioned and connected successfully\\
### Verify Device Connectivity The verification step in the provisioning dialog will test outbound connectivity from the device to the platform. It is also possible to verify connectivity from the Management Portal. Follow the steps to verify connectivity. 1. Go to **Monitoring** under **Operations** section in the navigation menu. 2. Expand the device tree and select the newly provisioned device. 3. Click **Ping Device** in the device toolbar.\ ![](/files/isOsTIQZfFGx7Sb6uhrh) 4. A dialog will then show if the platform has connectivity to the device as shown here:\ \\

Dialog showing the result of pinging the device

5. Click **Ok** to close the dialog. You have now provisioned a device and can continue to [create an Asset Hierarchy](/introduction/quick-start-guide/create-asset-hierarchy-with-emulated-data). *** ## Additional Setup To ensure successful device provisioning and connectivity to Azure, the following section describes additional requirements. ### Hostname Allow-list In order to provision a device, deploy modules and ingest data to Azure, a set of public endpoints needs to be whitelisted for outbound traffic from the edge device. This list is an example and will need to be updated to the specific installation of the platform.
NamePurposeHostnamePort(s)
Tricloud Nexus Support FilesContains installation files used during device provisioning.tricloudnexussupport.blob.core.windows.net443
Microsoft Linux Package RepositoryOfficial Linux package repository for IoT Edge runtime binaries.packages.microsoft.com443
Microsoft Artifact RegistryOfficial Artifact Registry for IoT Edge system container images.mcr.microsoft.com443
Official Tricloud Nexus Container RegistryOfficial Container Registry for Tricloud Nexus container images.tricloud.azurecr.io443
Azure IoT Hub Device Provisioning ServiceInstance specific Azure resource, used to connect devices to the platform.global.azure-devices-provisioning.net,
<instancename>.azure-devices-provisioning.net		443
Azure IoT HubInstance specific IoT Hub used for device management and data ingestion.<instancename>.azure-devices.net443, 5671, 8883
Azure Container RegistryInstance specific container registry used by edge devices to pull container images.<instancename>.azurecr.io443
Azure Storage AccountInstance specific cloud storage used for data ingestion.<instancename>.blob.core.windows.net443
# Create Asset Hierarchy with emulated data Understand and build an Asset Hierarchy to define your data collection. ## Introduction The Nexus platform makes it possible to create a virtual model of your setup or business that reflects the real world. This model is called an Asset Hierarchy, and consists of the following components: * Areas: Represents static locations or organizational structures. Areas can refer to physical locations (e.g. country, region, site) or organizational units (e.g. teams, business units like sales, marketing, or production). Other meaningful groupings can also be defines as Areas. * Assets: Assets represents entities, such as equipment (e.g. factories, production lines, motors, sensors). Assets can also represent virtual entities, that are not physical, like aggregations (aggregations of values from other assets). In general, areas represents organizational / geographic structures and assets represent equipment. It is possible to model everything into one or more separate Asset Hierarchies, depending on your preferences. For example, if you have 10 factories distributed across the world, you could model all 10 factories in the same Asset Hierarchy. However, it is recommended to instead having 10 separate Asset Hierarchies that models each individual factory. ### Data Connectors Data Connectors can be defined on an Area. A Data Connection represents a connection to a data source, that can be for example an OpcUA server, Modbus slave or a MQTT broker. The Area where the Data Connector is defined also defines the scope of visibility of the data source. For example, if the Data Collector is created on an FactoryA area, it means that all Assets created in a direct line under the FactoryA Area, are able to use the Data Source. The Nexus platform has an Emulator Data Connector that is able to provide simulated measurement, without having to connect to external data servers. The Emulator is used for this guide. ### Tags Tags are defined on Assets. Tags represents time series data that are either read or written to or from a data source, using a Data Connector. All tags must be assigned to a Data Connector. The tag defines the location to read or write data, and how often it is done. It also defines any aggregation or pre-processing that must be performed. A tag has both a name and a hierarchical name. The hierarchical name is determined from the location in the Asset Hierarchy where the tag is located. Here is an example:

Example of hierarchical tag name

In the example above, the tag is named "Tag". The tag is located on the "Asset" node, that is a child of the "Area" node. The "Area" node is again a child of the hierarchy root. The hierarchical tag name shows the full path from the root node to the tag. In the above example, the hierarchical name is: ***Root.Area.Asset.Tag*** The hierarchical name is created by concatenating the Alias properties on all nodes in the path from the root to the tag, separated by a punctuation. Since hierarchical names should be as short as possible, and node names can be very long (and contain special characters), the Alias properties can used to create a shorter identification of a node, to simplify the resulting hierarchy names. All hierarchy nodes have the Alias property, and the Alias default to the node name (without spaces and special characters), but can be changed afterwards. For example, an asset:

Changing alias for an Asset

By changing the alias for the Asset node, the resulting hierarchical name for the example tag is now: ***Root.Area.AS.Tag*** The root node Alias can be set with an empty string. This means that the "Root." part of the hierarchical name is removed. ### Meta Data Meta data are collections of key / value properties, that can be assigned to Assets, Areas and Tags. It is also possible to assign Meta Data to the entire Asset Hierarchy. The purpose of Meta Data is to provide context to the data that is collected into the Data Store. When an Asset Hierarchy is deployed to a device, the entire Asset Hierarchy structure, including the Meta Data, is replicated to the Data Store. When analyzing data in the Data Store, it is possible to access the Meta Data to provide context to ingested measurements. #### Asset Hierarchy It is possible to assign Meta Data to the entire Asset Hierarchy, by selecting the root node (the top node). In the "*Revisions & Properties*" section select the "*Properties*" tab. Add new Meta Data properties by clicking the "*Add property*" button.

Add Meta Data to Asset Hierarchies

#### Area Meta Data properties can be assigned to Areas, by selecting the appropriate area and editing the properties in the "*Area info*" section. Relevant properties could be information about the location.

Adding Meta Data to Areas

#### Asset To assign Meta Data to assets, select the appropriate asset in the tree structure, and select the "*Asset Info*" tab in the "*Asset*" section. This opens the "*Asset info*" section where Meta Data can be added. Relevant information could be properties describing the physical equipment.

Adding Meta Data to Assets

#### Tags Finally, is it possible to add Meta Data to individual tags. Select the asset, and select the "*Tags*" tab in the "*Asset*" section. In the "*Tag*" section, select the "*Store*" tab, where Meta data can be added. Relevant information to add could be unit of measure, status definitions, or other properties that describe the data source, to ensure that it is considered when doing analytics in the Data Store.
## Building Demo Asset Hierarchy In this guide, we will be building a demonstration Asset Hierarchy that uses simulated data. For this guide we define the fictional factory "Odense Factory", that produces plastic items by injection molding. The factory has a single production line, with 3 machines, that we want to monitor. The structure of the demo Asset Hierarchy should be like this:
The "Printing" node is an Area, that models everything regarding the plastic molding. "Line" is an Asset, that encapsulates all information that relates to the overall production line. The "Machine1", "Machine2" and "Machine3" Asset nodes are child nodes to the "Line" node, and each represent data from individual machines. Each machine produces data identifying the machine state and production. The product line produces environmental data, such as temperature and humidity. ### Create new Asset Hierarchy In the Nexus Portal, navigate to Assets in the Designer menu. This is where Asset Hierarchies are defined. * Press the "New Hierarchy" button to create the new hierarchy. * Enter a Hierarchy Name in the pop-up, to give the new hierarchy a name. An example is: "*Odense Factory*". * Enter a description, that describes the scope of the asset hierarchy. An example could be: "*This hierarchy represents the Odense Factory plastic molding facility.*" * Keep the default Data Store, that defines where all measurements will be persisted after data collection. * Click "*Create*" to create the new Asset Hierarchy. When the Asset Hierarchy has been successfully created, it will be shown in it's first version, which is version 1. There will be a root node visible, that has the same name as the Asset Hierarchy. This root node is special, and when selected the "Hierarchy Settings" and "Revisions & Properties" windows are shown, which makes it possible to view and set details on hierarchy root level. ### Create Hierarchy Structure * Select the root node, and set the Alias property to "OD". This means that the hierarchical name of all tags will be prefixed with "OD.". * Click the three dots at the root node, to get the context menu. In the context menu, select "*Add Area*" to create an Area node, and name it "*Printing*". Add Meta Data to the asset node: "vendor = acme".
* Create a new Asset node as a child of the newly created "*Printing*" node, and name it "*Line*". Add Meta Data to the asset node: "building = a1". * Create 3 new Asset nodes as a children of the newly created "*Line*" node, and name them "*Machine1*", "*Machine2*" and "*Machine3*". * Save the Asset Hierarchy by clicking the "*Save*" button, and thereby creating a new version. ### Define Data Connector To be able to generate data we need a Data Connector to identify the data source. In a real-life setup there would probably be a data server on the factory. Depending on the protocol that the data server provides, an appropriate Data Connected is selected. In this case we use the Emulator, and place it in the "*Printing*" Area node. Since the "*Line*" and the 3 "*Machine*" Asset nodes are children of the "*Printing*" Area node, they can all get data from the Data Collector. * Select the "Printing" Area node. * Create a new Data Connector by clicking "New data source" button, and select "*Tricloud Emulation*". * Save the Asset Hierarchy by clicking the "*Save*" button, and thereby creating a new version. ### Define Tags * Select each "Machine" Asset node, and create the following 2 new Analog tags on each node, by clicking the "New tag" button and selecting the analog measurement type. The properties for each tag should be set like this: | Name | Data Connector | Read Address | Meta Data | | ---------- | -------------- | -------------- | ---------- | | Status | Emulator | step;1;15;2;30 | | | Production | Emulator | random;0;100 | uom = kg/h | * Select the "Line" Asset node, and create 3 new Analog tags by clicking "New tag" button and selecting the analog measurement type. The properties for each tag should be set like this: | Name | Data Connection | Read Address | Meta Data | | ------------- | --------------- | ------------------ | ---------- | | Temperature | Emulator | sinus;10;30 | uom = deg | | Humidity | Emulator | sinus;60;90 | uom = % | | ProductionSum | Equation | \ | uom = kg/h | The *ProductionSum* tag uses symbolic equations to create a sum value from the production of the 3 machines. Open the Formula calculator editor by clicking the f(x) symbol:
Enter the tags names of the production values from the 3 machines, and assign each value the symbols a, b and c. Set the symbolic expression to "a+b+c" and click "Add Equation".
* Save the Asset Hierarchy by clicking the "*Save*" button, and thereby creating a new version. The demo Asset Hierarchy is now ready to be deployed to an Edge Device. # Deploy Hierarchy to Edge device Deploy the demo Asset Hierarchy to an edge device and verify the deployment. The Tricloud Nexus platform manages edge device deployment automatically, by analyzing the device configuration. It automatically creates deployment manifests based on the Modules, Applications and Asset Hierarchies that are set to be deployed, and manages secrets in a secure way. Both the deployment process and the edge device is monitored continuously, ensuring that the functionality performs as expected. 1. **Configure edge device** In the Nexus Portal, navigate to Configurations in the Management menu. This is where Edge Devices are configured for deployment. It is a prerequisite that an edge device is already provisioned for this step, and that it is online. * Select the edge device by clicking it in the device tree under "*Devices*". * Select the "*Modules*" tab. If there are any modules other than the "*edgeAgent*" and "*edgeHub*" modules, press the "*Reset*" button to create a new version of the configuration that is empty. On the pop-up, ensure that you do not deploy (No, reset only) and click "Ok". * Select the "*Asset Hierarchy*" tab, and click the "*Assign*" button. In the Assign Asset Hierarchy guide, select the Asset Hierarchy that was created for this demo, and assign it in its newest version. Click "*Next*" and ensure all Areas are selected in the Area Selection. Then click "*Done*". * Select the "*Modules*" tab to verify that several new modules have automatically been added to the device configuration. * To enable monitoring of the edge device click the "*Add module*" in the "*Modules*" tab. Select the "*Tricloud DeviceMonitorModule*" and click "*Select*". The module is then added to the list of modules on the tab. * Save the device configuration by clicking "*Save*". 2. **Deploy to the edge device** The device is now configured, and ready to be deployed. * Click the "*Deploy*" button, which creates a pop-up that gives you the option to deploy now or schedule the deployment for later. Click the "*Deploy Now*". The deployment process starts, and after a while the last line in the log should read "*Deployment completed*". This means that the edge device accepted the new configuration, and started applying it, by commencing download and startup of new container images. 3. **Verify and Monitor deployment** In the Nexus Portal, navigate to **Monitoring** in the Operations menu. This is where Edge Devices are monitored, and any errors or temporary interruptions in functionality is detected. After deployment has completed, the edge devices receive their new configuration as soon as they are online. The following process of applying the new configuration might take time, since the edge device potentially needs to download and start-up the new modules. Therefore, modules that have been deployed, but are not yet started on an edge device, are marked as "*Starting*" and greyed out in the module list. * Select the edge device, used for this demo, in the Devices tree. The Monitoring overview will show the current state of the device. The device status should be "*Connected*". If it is not connected, press the "*Ping Device*" button to test connectivity. The *Modules* section shows the status of all modules that are deployed on this device. If the Asset Hierarchy was created and deployed according to this guide, the resulting modules should be:

Modules deployed using this guide

Ensure that all modules are in "*running*" state. To ensure that data collection run as expected, verify that the Emulator data connector is in running state.

Data Connector monitoring, for the example deployment

The *DeviceMonitorModule* collects device metrics, and monitors the device state with respect to CPU, disk, memory and other relevant information. The status of the device monitor should also be running. Data collection is now running, and measurements will be saved to the Data Store. Follow the guide in "*Gain Insights from Queries*" to learn how to access and get value from the collected data. # Gain Insights from Queries The Tricloud Nexus Query Editor is a powerful tool designed to help users query, analyze, and visualize data effortlessly. This guide will help you quickly get started with using the Query Editor of Tricloud Nexus to analyze and gain insights from data efficiently. *** ## Introduction The Tricloud Nexus Query Editor is a powerful tool designed to help users query and analyze data effortlessly. Built on the Azure Data Explorer Query UI, it uses KQL (Kusto Query Language) for efficient data access and exploration. ### Learning Kusto Query Language (KQL) Here are some links to help you get started with the learning the KQL language. * Kusto Query documentation: * Quick Reference Guide: * Kusto Cheat Sheet; *** ### Accessing the Query Editor 1. **Login to Tricloud Nexus**: * Navigate to the Tricloud Nexus platform using your browser. * Enter your credentials and click **Login**. 2. **Open the Query Editor**: * Click on the **Query Editor** tab located in the navigation menu.

Query Editor

3. **Select the Database:** * In the Query Editor, your workspace is pre-configured to access the Azure Data Explorer database. * Ensure you have the necessary permissions to query the database. * Select the database as seen in the example screenshot above, and take notice that the database is selected above the query editor using the convention *cluster/databasename.* * In the example above the selection is: tciotadxcluster.westeurope/TimeSeriesSandbox02 which may differ depending on your installation. *** ### Creating your first Query 1. **Familiarize yourself with KQL**: * The Query Editor uses KQL (Kusto Query Language) to query data. If you're new to KQL, refer to the [#learning-kusto-query-language-kql](#learning-kusto-query-language-kql "mention") 2. **Build Your Query**: * Use the query editor interface to type your KQL commands. * Example: * This Query will show the name all Asset Hierarchies that has been deployed to a device, and sort them alphabetically by the name of the Asset Hierarchy: ```kusto AssetHierarchy | distinct HierarchyName | order by HierarchyName asc ``` 3. **Preview your Query**: * Click **Run** to execute the query and preview the results in the **Results** panel.

Running your first Query

*** ## Database Tables The database hosts several tables that are crucial for exploring and analyzing your data. This section provides an overview of the most commonly used tables to help you get started. You can view the database structure by expanding the nodes in the **Database Explorer**. Among the available tables, the most relevant ones include:

The most relevant Tables for gaining Insights can be found in the Database Explorer

* **AssetHierarchy**: This Table contains information from Asset Hierarchies, that has been deployed to a Device. The Table details the organizational structure of deployed assets, featuring the latest version of each node— whether it is an Area or an Asset within any Asset Hierarchy. * **AssetHierarchyMetadata**: This Table contains metadata information from Asset Hierarchies, that has been deployed to a device. The Table provides metadata for all Area/Assets and Tags that has been configured for Asset hierarchies. * **Measurements**: Stores time-series measurements and events associated with your assets. The Table contains the actual metrics that has been collected from your devices. {% hint style="info" %} All timestamps in any Timestamp column is always represented in the Date format ISO8601 as UTC unless otherwise specified {% endhint %} *** ### AssetHierarchy Table This Table contains information from Asset Hierarchies, that has been deployed to a Device. The Table details the organizational structure of deployed assets, featuring the latest version of each node— whether it is an Area or an Asset within any Asset Hierarchy. Running this query, lets you get a list of latest available AssetHierarchies in the Database. ```kusto AssetHierarchy | distinct HierarchyName, HierarchyId, HierarchyVersion | order by HierarchyName asc ``` Beneath is an example result of running the query

Example of Query output showing current Hierarchies in the Database

Now that we can see all available Asset Hierarchies in the Table, we can now refine our search, to only show all Nodes from a specific Asset Hierarchy. Running the following query, will show the Asset Hierarchy nodes for the Asset Hierarchy called "*Odense Factory*". The Query only includes some of the available columns using the *project* operator. ```kusto AssetHierarchy | where HierarchyName == "Odense Factory" | project HierarchicalName, Type, Description, IsDeployed, DeploymentTimestamp, DeviceId | order by HierarchicalName asc ``` Here is an example result of running the query

Showing all Asset Hierarchy Nodes from the Odense Factory Hierarchy

Notice that by ordering the query result by HierarchicalName displays the result exactly as it was Modelled in Tricloud Nexus in that version. Also notice that you can see whether a Node has been deployed, when it was deployed and the device that was targeted for the deployment.

The Modelled Asset Hierarchy structure

*** ### AssetHierarchyMetadata Table This Table contains metadata information from Asset Hierarchies, that has been deployed to a device. The Table provides metadata for all Area/Assets and Tags that has been configured for Asset hierarchies. All metadata for an Area/Asset or Tag that has been deployed to a device, can found by running the query beneath. The query displays all metadata Key/Value objects for all available Asset Hierarchies. It removes some less important columns from the result (Id, IngestionTime, DataType). It then orders the result by the Type of metadata. ```kusto AssetHierarchyMetadata | project-away Id, IngestionTime, DataType | order by Type asc ``` Here is an example result of running the query

Available Asset Hierarchy Metadata

Notice that the first 2 rows are metadata about an Area that seemingly sets a GPS coordinate for the Area. The rest of the rows are metadata about a Tag such as uom (Unit Of Measure), description, ranges etc. You can combine an entire AssetHierarchy with the available metadata for all Area/Assets or Tags into a single query by joining the *AssetHierarchy* and *AssetHierarchyMetadata* Tables. The query combines all metadata available for a specific node into a json document (Key/Value) and stores this in the Metadata column. ```kusto AssetHierarchy | join kind=leftouter AssetHierarchyMetadata on Id | where HierarchyName == "Dallas Factory" | project Id, Name, HierarchicalName, MetadataKey = Key, MetadataValue = Value, DeploymentTimestamp | summarize Metadata = make_bag(pack(MetadataKey, MetadataValue)) by HierarchicalName | order by HierarchicalName asc ``` Result of running Query

Showing the Asset Hierarchy Structure along with all available Metadata for each Area/Asset or Tag

*** ### Measurement Table The Measurement Table stores time-series measurements and events associated with your assets. The Table contains the actual metrics that has been collected from the devices. The following Query, will find all available metrics/measurements that has a StartTimestamp between 17. the dec to 20. the dec. (UTC) for the Tag with the HierarchicalName *OD.Printing.Line.Temperature,* then order the result by StartTimestamp descending: ```kusto Measurements | where StartTimestamp between (datetime('2024-12-17T00:00:00') .. datetime('2024-12-20T00:00:00')) | where HierarchicalName contains "OD.Printing.Line.Temperature" | order by StartTimestamp desc ``` Result of running the Query

Measurement Query result

The result shows the structure of the Measurement Table, the Table has the following Columns: * **Id -** The Id of the Tag that governs measurements * **HierarcicalName -** ISA95 name for the Tag that governs the measurements * **TagName -** Shorthanded name of the Measurements * **TimeGenerated -** The UTC time the Measurement was generated at the Data Collector * **StartTimestamp -** The UTC start time of the Measurement * **EndTimestamp -** The UTC end time of the Measurement. Many measurements does not have an endtime specifed, denoting that the measurement does not have timespan. * **Type -** Measurement type. Can be either Analog, Digital or String. The Type depends on Tag type that was configured in the Asset Hierarchy. * **Value -** The value of the measurement as a real data type. This will likely only be set for measurements of type Analog or Digital. * **ValueDigital -** The value of the measurement as a boolean data type. This will likely only be set for measurements of type Digital and Analog. The database will automatically try and convert the value of the measurement to a boolean, by converting 1 to true and 0 to false. * **ValueString -** The value of the measurement as a string data type. This will likely only be set for measurements of type String. This is a very flexible data type and can be used for metrics that carries a complex data type such as Json. * **Quality -** The quality of the measurement. The quality of each measurement is set by the data collector on the device, that is used to collect the measurement from the destination data source. If a given measurement has a quality other than the value *good,* it is not recommended to use the measurements for training an AI model. {% hint style="info" %} The Measurement Table is indexed on the StartTimestamp column, which significantly improves Query performance for queries that starts by filtering data on this column. Example: `Measurements` `| where StartTimestamp > ago(2d)` {% endhint %} *** ## Queries Please refer to the KQL query help section for guidance and examples on using the KQL language to explore data in Tricloud Nexus. [Queries](/management-portal/insights/queries) *** # Nexus Edge SDK An introduction on how to use the Nexus Edge SDK in a custom developed module. ## What is the Nexus Edge SDK? The SDK provides building blocks for quickly setting up your module, adding custom logic, and deploying it to edge devices. Develop custom modules and integrate them into the Tricloud Nexus Edge environment using this collection of .NET NuGet packages. ### How to get access to it? The Nexus Edge SDK is available in a private NuGet feed hosted in Azure DevOps, where new features are constantly released. To start using the NuGet feed, you need to have been granted access to the Tricloud Support portal. This is only done through direct contact with Tricloud, reach out to us if you are interested. ## Tutorials The best way to get started is to follow one of the SDK tutorials, which guide you from setting up your project (in Visual Studio or VS Code) to implementing custom logic and deploying the containerized module through the web portal. All the tutorials use the building blocks contained in the Nexus Edge SDK to get a module up and running fast and efficient. ### Getting Started The tutorial guide and code samples can be found here: * Create a new module project from a template or empty project. * Add the required Tricloud Nexus SDK dependencies. * Create a Dockerfile and push your image to a container registry. * Utilize the SDK’s built-in features and add custom logic. ### Direct Methods The tutorial guide and code samples can be found here: * Add the required Tricloud Nexus SDK dependencies. * Create a Dockerfile and push your image to a container registry. * Import and deploy the module via the web portal. * Implement and call direct methods from the web portal. ### Data Connector The tutorial guide and code samples can be found here: * Add the required Tricloud Nexus SDK dependencies. * Create a Dockerfile and push your image to a container registry. * Import and deploy the module to an edge device through the web portal. * Configure an asset hierarchy to model collected data. * Build an application template that includes the module. * Test data connection and visualize the results in the web portal. # System Requirements # Installation Guide # Quick Start Guide # Accessing the Platform # Purpose and Scope The purpose of the Platform Architecture documentation is to provide a shared understanding of how the Nexus Platform works, the components involved, how it is used, and what to consider when designing a solution. The intended readers of the documentation includes: * **Platform Operators**\ **T**o understand the overall core concepts of the Nexus platform, providing insights into the functionality that supports functions like configuration, deployments, monitoring and day-to-day operations. * **Developers & Data Scientists**\ To understand how to integrate with the platform, extend it with modules and connectors, and build/ship custom analytical models into production. * **Solution/Enterprise Architects**\ To understand the core components that make up the Nexus platform, including hosting, security, data flow and integrations, to support design decisions. * **Reporting/Business Stakeholders**\ To understand where data originates, how it is governed and accessed, and how insights are produced. # High-level Overview This documentation is an introduction to the overall structure and design of the Tricloud Nexus platform. It explains how components work together to provide a seamless and scalable IoT solution.
*** ### Platform Features All management, operations, and configuration happen in the **Nexus Management Portal**, organized into three pillars: ### Applications An application is a packaged set of one or more **modules** that work together to do a specific job. It is a “bundle” that includes the modules, their configuration, versions, and how they are connected. The Nexus platform provides the following functionality: * **Build** and version modules and applications, using built-in, custom and third-party containers. * **Design** and model data storage, collection and models. * **Integrate** with external systems and services. [More information](#applications) ### Operations Operations cover day-to-day work that keeps systems reliable and safe. It includes the following areas: * **Manage** security, provisioning, and deployments on devices. * **Maintain** the platform by using diagnostics, remote service tools, and Update Center. * **Monitor** alarms, data flow, and device health in real time. [More information](#operations) ### Insights Insights is about turning your data into answers people can use. It covers the following areas: * **Explore data** with built-in query tools and AI assistance * **Drive improvements** using dashboards, module/app rollouts, and targeted optimizations * **Apply analytics** and custom ML/AI models to turn data into actions [More information](#insights) *** ### Execution of Modules & Applications Tricloud Nexus features a Module and Application Store, that enables automated deployment of containers from cloud to edge, for execution in a near real-time environment. You can build applications in the platform based on a selection of multiple modules, thereby packaging a set of modules for a specific use-case. 3rd party containers can be imported as modules to the platform as well. All modules and apps are handled with full traceability and versioning, making it easy to re-deploy to previous versions id necessary. By having a module and application store you get full control of your deployed solution and gain the possibility to deploy eg. AI algorithms to the edge on a continuous basis. The easy deployment of new improved models will help accelerate your continuous improvement efforts. *** ### Data Collection (DataOps) **Connect** to virtually any data source or OT system like PLC, SCADA, MES or robotics. Connect to standalone IoT devices measuring temperture, humidity, flow or vibration. Connect to barcode scanners for traceability or Computer Vision cameras for streaming video or quality control operations. Connect to company wide UNS Brokers for access to enterprise real-time data. Connect to FTP or file shares to either transfer or analyze files at the edge or cloud. **Collect** data from data sources, validate it, aggregate and enrich it with metadata, and assign it to the asset hierarchy for a unified structure. Structure data according to the ISA-95.2 standard and use the unified asset hierarchy to handle deployment to many edge devices. Use Nexus Management Portal for configuration or integrate 3rd party systems through the API or CLI for fully automated workflows. **Process** data before storing in cloud. Optionally aggregate and compress data before storing in cloud for increased performance and operational cost optimization. **Store** data in the cloud, to one or more endpoints / historians, including Datalake, SQL databases, Azure Fabric and more. # Applications The applications features can generally be organized into 3 main elements: * **Design** - data collectors, models and publish to UNS and data stores * **Build** - use existing modules or 3rd party containers to build applications or build your own modules using our SDK * **Integrate** - to legacy systems at edge or build your own service offerings by extending the platform in cloud
*** ### **Design** Setup your data collection routines in 3 easy steps: **Data collectors**\ Configure your edge devices with the necessary data collector modules from the built-in Module & Application Store. **Unified Namespace**\ Connect to data providers and define an asset model to organize your data in a logical and manageable structure. (Supports ISA 95.2, and ingestion into a companywide UNS) **Data Stores and Historians**\ Store your data in a cloud-based time series database or historian. *** ### **Build** Configure and build your solution using the built-in Modules and Application Store: **Platform modules & applications**\ Tricloud Nexus contains dozens of modules & applications, ready to use as part of your solution. **SDK - Software Development Kit**\ Use the software development kit to develop your own modules or apps. Both .NET and Python is supported. **3rd party containers**\ Import containers as modules from 3rd party providers, use thousands of open source applications, or import trained AI algorithms. *** ### **Integrate** Comprehensive options for integration to other systems: **Modules & Applications on Edge**\ Integrate to legacy systems including SCADA, MES, LIMS and more. Run applications on edge for maximum operational efficiency. **Cloud**\ Integrate the platform with your enterprise by using the Nexus REST Api or standard Azure resources to build additional applications to extend the platform. **Service management**\ Integrate to companywide service management solution for easy organizational anchoring. # Operations The O**perations** feature of the platform includes functions to support reliable operation 24/7. Operations can generally be organized into 3 main elements: * **Manage** - provision, manage and deploy to all your devices * **Maintain** - diagnose and remotely upgrade installations * **Monitor** - device health, alarms and dataflow
*** ### **Manage** Manage all your devices from Tricloud Nexus management portal: **Security**\ The solution supports Microsoft Defender for IoT for central security monitoring. **Provisioning**\ Setup your edge devices secure and efficiently in an automated workflow. **Deployment**\ Configure any module or application and deploy to an edge device or to multiple edge devices in an automated workflow. *** ### **Maintain** Ensure highest possible performance of your IIoT solution: **Diagnostics**\ Built-in diagnostic tools gives full insight into how each edge device and each module is performing. Access diagnostics logs and interact with your modules through the management portal. **Remote service**\ Remotely maintain and manage all devices, restart modules or edge devices if necessary, thereby mitigating any anomaly or operational incident. **Update center**\ Update all devices easily through the update center that automatically keeps track of versions on all devices and modules running on edge. *** ### **Monitor** 24/7 monitoring of the entire solution, with advanced features: **Alarms**\ System alarms gives a fast and easy overview of the current state of the system. **Data flow**\ Continuous monitoring of the flow of data, ensures focus on stable connections to all technical data providers. **Device health**\ Edge device health information dashboards enables predictive maintenance and improves overall uptime. # Insights The Insights feature of the platform enables deeper knowledge of your data, so you can optimize your processes. It can generally be organized into 3 main elements: * **Visualize** - data from your assets in time series explorer or dashboards. Bring your own visualization tools. * **Analyze** - data based on advanced analytics tools from Azure Data Explorer including ML features, or use your preferred analysis software * **Improve** - your process by training ML models and deploy them at the edge
*** ### **Visualize** Visualize your data through time series database or use your own visualization tools: **Time series**\ Visualize time series both historically and in real-time directly from your assets. **Dashboards**\ Build your own dashboards using dozens of graphical objects for easy overview and analysis. **Customer applications**\ Use virtually any visualization tool and integrate into existing business intelligence solutions. Visualize your data using tools like Power BI, Grafana, Tableau, Excel and many more. *** ### **Analyze** Analyze huge amount of data through advanced built-in analysis tools based on Azure Data Explorer or use your own toolkit. **Query**\ Query your data using Kusto (KQL) with Azure Data Explorer for deeper insights, comparison and analysis. **AI**\ Azure Data Explorer uses KQL that has anomaly detection and forecasting functions to check for anomalous behavior. **3rd party tools**\ Store historical information in a data lake and get access to the information from 3rd party tools including analytic platforms such as Databricks, Dataiku, Jupyter Notebooks, Apache Spark, Power Apps and many more. *** ### **Improve** Enable closed loop analytics by using edge modules to do process optimization, re-train and control the process: **Process optimization**\ Improve your process optimization efforts by detailed insights through data. **Train model**\ Optimize your ML algorithms by automated re-training and deployment and integrate your MLOps process with Tricloud Nexus fast and easy. **Control**\ Make your own optimization algorithms based on data and rules of thumb, and deploy on edge for guidance or direct control of the process. *** # Reference Architecture * Edge Layer (devices, on-prem services, buffering, offline behavior). * Site Network & DMZ placement (factory floor, DMZ, northbound links) * Cloud Layer (control plane, data plane, storage/compute, APIs) * Web Portal / API / CLI surfaces # Core Components This section breaks down the key architectural components of the Nexus Platform and how the platform integrates with customer infrastructure, both on-site and in the cloud.

Nexus connects to plant systems at the edge, organizes them with an ISA-95-aligned hierarchy, collects and processes data via tags, enriches it with metadata, and serves it through cloud APIs and time-series analytics for dashboards and custom apps.

## Customer Site (Factory Floor) Typically, the production systems that contains the data you want to collect exists on the the factory floor. It is a secure, non-internet-facing zone that contains the operational data sources we want to read from. It can be: * **Databases / Historians** * **Realtime data sources (OPC UA / MQTT / MODBUS / ..)** * **MES/SCADA systems** * **FTP/File shares**. Nexus Edge devices do not need inbound connections from the Internet. They *can* be installed directly on the factory floor, but it requires that the edge devices are able to create an outbound connection to requires is very often a very restricted network, where ### On-site Edge Devices Since Nexus does **not** run cloud endpoints here and does not require inbound internet access to OT. ### Purpose in the architecture * Provide the **authoritative data** about equipment, process values, quality results, and events. * Keep production systems **isolated** from the internet and IT workloads while still enabling data acquisition. ### Connectivity principle * **No open internet on the factory floor.**\ All northbound communication is routed through an **Industrial DMZ** (on-site Edge zone). OT assets never accept inbound connections from the cloud or enterprise networks. * **Southbound protocols stay in OT.**\ PLC/fieldbus/SCADA traffic remains local; Nexus Edge connectors in the DMZ read from OT over standard interfaces (e.g., OPC UA/DA, SQL, SMB/FTP) using tightly scoped credentials. ### Typical systems in this zone * **OPC servers** (gateway from PLCs/SCADA) * **Databases & historians** (SQL/OSISoft/ADX on-prem) * **MES/Manufacturing apps** (production orders, genealogy) * **File servers / FTP drops** (batch reports, machine exports) * **Other OT applications** (alarm/event systems, lab systems) ### Security & access expectations * **Network:** OT VLANs/subnets are firewalled; only **allowlisted** connections from the **DMZ** to specific hosts/ports are permitted. * **Accounts:** Use **read-only**, least-privilege service accounts; prefer certificate-based auth for OPC UA and key-vaulted credentials for databases and shares. * **Change control:** Any new data access is approved via site change procedures; routes and ports are documented. * **Resilience:** Source systems remain operational even if the WAN is down; the DMZ buffers data until cloud connectivity returns. ### What is deployed here? Nothing cloud-facing. The factory floor hosts **your existing OT systems** only. Nexus components that interact with these systems (Edge runtime and data connectors) are deployed **in the on-site DMZ**, not inside OT. This separation preserves OT security while enabling controlled data collection toward the cloud. ### **Cloud Components** **Nexus Management Portal**\ Design hierarchies, configure connectors/tags, deploy to devices, and monitor health. **IoT Hub**\ Secure device messaging between edge and cloud (bi-directional for commands/config). **Nexus REST API**\ Programmatic access for inventories, configs, deployments, and data—used by custom apps/integrations. **Data Explorer (time-series analytics)**\ Time-series storage and query over operational data. **Hierarchy metadata** (from Areas, Assets, Tags) is synchronized after deployment so every measurement is queryable with context (unit, owner, location, etc.). **Log Analytics**\ Unified logging and diagnostics from edge modules and cloud services. ### On-site Devices (Edge) **IoT Edge Linux VM running Nexus Edge** * Hosts **Data Connectors** for OPC UA, Modbus, MQTT, FileShare/FTP, Historian, Camera/scene, Emulator, and custom connectors (via the Nexus SDK). Connectors are configured on **Area** nodes so connectivity mirrors your plant layout and governance. * Uses an **ISA-95 aligned hierarchy** of **Areas** and **Assets** to keep data, access and jobs organized exactly where work happens. * **Tags** on Assets define the actual data points to collect and how to treat them (type, scaling, sampling, calculations, storage/publish). * Optional **Jobs** at the Area level automate file flows between shop-floor systems, edge modules, and cloud storage. ### Customer Site Systems **Databases, MES, historians, file shares/FTP**\ Nexus connects to on-prem systems via **Edge Data Connectors** placed where the systems live (per site/line/area). Connectors normalize different protocols into one common Nexus format and keep data local if the internet is down, forwarding buffered data when links return. ### Reporting & Applications * **Dashboards over time-series** for trends, alarms, OEE inputs, energy, etc., using the contextual metadata you define. * **Custom applications** built on the REST API + queries. * **Optional Power BI** to blend operations with business data. # Page 1 # Data Flow * Connect → Collect → Process → Store → Publish (end-to-end paths). * Real-time vs batch flows; back-pressure and buffering (Edge↔Cloud). # Integration * External systems (UNS/MQTT, OPC UA/Modbus, files, historians). * Public APIs & Webhooks (extensibility points) * Custom Connectors & Modules (SDK, Module Store, deployment pattern) # Roles This section introduces the core roles in the Nexus Platform and how they interact with it. While one person may perform multiple roles, defining them separately clarifies ownership, access control, and workflows.

Roles in the Nexus platform

### Operator The Nexus operator is responsible for creating and maintaining applications and data collection while devices stay healthy and secure. This is done using the Nexus Portal, where typical tasks are: * Monitoring devices * Investigating alarms for detection of issues * Log analysis for root-cause analysis (AI powered) * Dashboards for monitoring data flow and custom applications * Device Management * Provisioning new devices * Configuring security * Deploying functionality * Modelling * Setting up Asset Hierarchies to model physical processes and collect data * Manage modules in the Module Store * Create applications as combinations of modules ### Data Scientist The Data Scientist is responsible for turning normalized plant data into actionable insights and deployable models that flow back into operations while ensuring traceability and quality. Nexus ensures that collected data is consolidated in the cloud, in any data store (Fabric, Data Lake, SQL). This enables the data scientist to use the tool stack they’re most comfortable with (Python, R, Data Bricks, SQL). Typical tasks are: * Exploring time-series data with ISA-95 context and metadata using query and visualization tools * Performing feature engineering and experimentation (notebooks/ML frameworks) * Developing analytical or processing models with the preferred toolchain * Continuously improving models using an [MlOps lifecycle](/platform-architecture/roles/model-development-cycle). ### Reporting Stakeholder The Reporting Stakeholder is responsible for delivering trusted, easy-to-understand metrics and reports to internal and external stakeholders. This includes both scheduled and ad-hoc reports and is potentially done using the Nexus Portal dashboards or query tools directly, or using connected BI tools, where typical tasks are: * Aggregating time-series data with ISA-95 context and metadata * Building or scheduling recurring reports and alerts for stakeholders * Reviewing KPIs and trends with drill-downs ### Developer The Developer is responsible for extending Nexus with additional custom modules, data connectors and data stores, if required. This includes scripted automation like CI/CD pipelines, for example when new modules are created. Additionally, custom integrations to external systems , and integrations while keeping deployments repeatable and observable. This is done using the Nexus Portal, Module Store, SDKs, and the API/CLI (often automated via CI/CD), where typical tasks are: * Building custom data connectors and edge/cloud modules * Creating applications as combinations of versioned modules * Defining configuration schemas, secrets, and health checks * Automating provisioning, security, and deployments at scale * Integrating with enterprise systems (APIs, UNS/MQTT, data contracts) * Monitoring telemetry, logs, and diagnostics; iterating safely with rollbacks # Model Development Cycle The Nexus platform supports custom analytical and processing models that can be deployed directly to Edge devices. These models may include anything from AI and machine learning algorithms to rule-based calculations and signal processing logic. To manage model development effectively, it is recommended to follow a structured and automated Model Development Cycle — a process inspired by MLOps, which extends DevOps principles to include data and model artifacts. The overall goal of the process is to improve the following: * **Speed:** Reduce the time from experimentation to production deployment by automation. * **Reliability:** Use automated and reproducible builds with safe rollbacks. * **Quality:** Continuously measure model and data quality through automated validation. * **Compliance:** Maintain full traceability of data, code and model versions. ### Lifecycle The lifecycle defines a continuous improvement loop for your models, typically automated through CI/CD pipelines. Each step ensures traceability, repeatability, and collaboration between stakeholders. The lifecycle of the continuous model improvement process contains the following steps:
The process begins when weaknesses in a deployed model are identified, such as low prediction confidence, poor accuracy (model drift), or business KPI deviations. * **Train**\ A **data scientist** or **developer** retrieves relevant datasets — such as misclassifications, low-confidence predictions, or manually labeled examples — from the Nexus **cloud data store**.\ Model training can take place locally (offline) or in a cloud development environment.\ The result is a new model version, including updated code, configuration, and metadata, which should be committed to a code repository. * **Package**\ Once code is checked in, automated build pipelines package the model and its dependencies into a containerized format (Docker image). Each model is treated as a module, versioned and reusable across multiple assets or sites. * **Validate**\ To ensure the quality of the model, automated tests should validate performance against predefined cases. If validation passes, the model image is then published to a Docker repository or directly to the Nexus Module Store. * **Deploy**\ From the Nexus Web Portal, a platform operator can deploy the new model version to either one or more Edge devices (canary deployment), by using the Update Center to update the desired Device Configurations and deploying the changes. * **Monitor**\ Once the new model has been deployed, then model must be monitored continuously in respect to health, performance, drift, data quality and for example business KPIs. The Nexus platform provides tools for this in the form of dashboards, alarms and device monitoring capabilities. ### MlOps in Nexus The figure below shows how the model development cycle can be implemented using the Nexus platform. The Model Development Cycle in Nexus enables a complete closed-loop workflow for model innovation, where continuous improvement is based on operational data located in cloud data store.

Module development cycle using Nexus

The automated pipeline integrates with the Nexus platform, by uploading the model to the Module Store, using either the CLI or API. While deployment can be done automatically, it can also be done manually by an operator. Model performance must be continuously monitored, where the Nexus Platform provides several tools in the Web Portal, like dashboards, alarms and device monitoring, to supports the operator. For detailed model performance analysis, the data stores can be used. # Security Tricloud Nexus is designed with a strong emphasis on security, leveraging Microsoft Azure technologies to ensure robust protection across all components. Cloud infrastructure integrates Azure IoT and Azure security fundamentals, providing secure communication and role-based authorization through Microsoft Entra. At the edge, Azure IoT Edge runtime security enhances device and network protection. IIoT security is a large topic, below is a short list of the most important key technologies supported by Tricloud Nexus: * Virtual networking with private endpoints between cloud and edge * Device attestation with either Certificates – X509 / TPM / Symmetric keys * Secure communication between edge and cloud (TLS) * Option for layered edge topology, supporting DMZ and OT zones using gateways * Support for Microsoft IoT defender to mitigate current security risks ### **Cloud** The platform is built on Microsoft Azure technologies, including Azure IoT and Azure security fundamentals. Azure IoT enables seamless integration and management of IoT devices, providing robust capabilities for connecting, monitoring, and controlling devices across a wide network. Security is a top priority, with the platform leveraging Azure security fundamentals to ensure data protection and compliance. Azure security fundamentals encompass a range of security practices, including identity and access management, encryption, threat detection, and response. The platform integrates with virtual networks and supports private communication, ensuring secure data transfer within isolated network environments. Role-based authorization is implemented using Microsoft Entra, formerly known as Azure Active Directory (Azure AD), providing granular access control based on user roles. Authentication is seamlessly integrated with customers' Microsoft Entra for user authentication, ensuring a streamlined and secure access experience. ### **Edge** The edge computing component of the platform is based on Azure IoT Edge. Azure IoT Edge runtime extends cloud capabilities to the edge, allowing for local data processing and analysis, reducing latency, and improving responsiveness. Security is paramount, and the Azure IoT Edge runtime ensures that all edge devices are secure and compliant with industry standards.  Security at the Edge can be further enhanced by configuring a layered network topology to enhance the security and reliability of edge deployments, and communication between Edge and Cloud can leverage additional encryption layers like VPN. The platform's edge architecture supports a multi-layered security. ### **Software development** The development process follows well-known code review practices, ensuring that all code is getting proper attention in regard to quality and security. DevOps principles are employed to streamline and automate development, integration, testing, and deployment processes, promoting continuous delivery.  To ensure a high quality code base, static code analysis is performed. The static code analysis scans for the most common OWASP issues that can be detected statically. This ensures that the codebase is regularly scanned for vulnerabilities, helping to identify and mitigate potential security issues early in the development cycle.  Additionally, third-party software and libraries are analyzed for vulnerabilities in third-party components, providing insights and recommendations for remediation. This comprehensive approach to development and security ensures that the platform remains robust, secure, and reliable. # Network Security Choosing a network security model is about balancing risk, cost, and operability. The goal is to protect production systems from external threats while still allowing the platform to be deployed, configured, updated, and monitored. Edge devices always communicate with a cloud based management endpoint for identity, configuration and deployment information. Edge devices always initiate connections to management endpoints outbound. This means that there are no inbound exposure. Authentication is done using either X.509 device certificates (preferred for lifecycle control and revocation) or Shared Access Signature (SAS) keys. Designing the network security is a compromise between complexity and the level of security. By adding additional security layers you reduce exposure but also increase the design complexity, operational effort, and the number of components to maintain. Some of the most relevant security layers that can be applied are: * **Segmentation**: Place the edge device on its own VLAN/subnet and control traffic with firewalls at each zone boundary (e.g., IT ↔ DMZ ↔ OT). Allow only the minimum northbound egress (typically TCP 443 to named cloud endpoints, plus DNS/NTP) and the minimum southbound ports to equipment. Combine with host firewalls and NAC on switch ports. * **Gateways**: Introduce a dedicated gateway edge in the DMZ to terminate all cloud management traffic, while one or more nested edges on the factory floor communicate only with the gateway over mutually authenticated, encrypted channels (MQTT/TLS). The solution keeps internet-reachable components out of OT zones. * **Private Networking**: Remove public internet exposure for management traffic by using site-to-site VPN, MPLS, or ExpressRoute to reach cloud services on private IPs with private DNS/endpoints. This reduces reliance on open internet paths and simplifies egress policy, at the expense of higher network complexity. ### Edge on the factory floor The device resides on an OT VLAN and connects directly outbound to cloud management endpoints over TLS. ### Edge in a DMZ The device is placed in a screened network segment. It connects outbound to cloud and only the necessary southbound ports are opened into OT. ### Gateway in the DMZ with nested edge A hardened gateway in the DMZ handles all cloud traffic; one or more nested devices on the floor communicate only with the gateway over a controlled, TLS-protected channel. ### Private network Cloud management endpoints are reached over a private path (VPN/ExpressRoute/MPLS) with private DNS/endpoints. No public internet is required for management traffic.
# Security Architecture An in-depth overview of the security measures embedded in the platform. * Identity & Access (roles, tenants, least-privilege) * Network & Segmentation (site, DMZ, cloud boundaries) * Data Security (at rest, in transit, secrets) * Compliance considerations (e.g., audit, traceability)
* Secure Device Attestation (X509 certificates) * No inbound ports open * No exposure to public Internet * No public IP * Segmented Network Support Transparent gateway: * Application deployment * 2-way communication * Remote management * Private Docker repository # User Roles and Permissions # Authentication and Authorization # Role-based Access Control (RBAC) # Scalability How the platform handles scalability to accommodate varying customer needs.
# Use Cases Examples of how the platform is implemented in real-world customer environments.

Use cases for Manufactoring site

Model development (DevOps)
# Roadmap A brief mention of upcoming features or improvements planned for the platform. # Unified Namespace ## What is the Unified Namespace (UNS)? A Unified Namespace (UNS) is an architecture and design pattern for structuring data producers and consumers within a real-time industrial operations environment. By standardizing data from disparate systems, it streamlines data governance, sharing, and analytics. This unified data source ensures stakeholders across the enterprise can access, integrate, and analyze critical insights more efficiently, driving faster decision-making and operational agility. The Unified Namespace (UNS) is all about making data management and system connections easier to handle, breaking down the barriers and complications often found in older systems and architectures. It's like having a common language in a company where every machine and software can understand and use data without confusion. #### What Is The Unified Namespace (UNS)? In the world of Industry 4.0, understanding the Unified Namespace (UNS) is key to grasping how modern industries are evolving. But what exactly is the Unified Namespace? **Understanding The Concept:** The Unified Namespace (UNS) is the structure of your business and all of the events. It's not a specific piece of software or a physical entity, but rather a model for organizing and accessing data across an entire enterprise. Think of it as a universal language or a common paper where all data across a company's business, including various systems, machines, and processes, is written, making it accessible and understandable to anyone, anything, and any part of the business. **The Need For UNS:** In Industry 3.0 settings, each machine and software system often operates in isolation, using its own data format. This leads to inefficiencies and communication barriers, making it challenging to scale and integrate new technologies.
The Unified Namespace addresses these challenges by offering a common ground where all data is standardized and shared, ensuring seamless communication across different systems. **How It Functions:** Every Component in the enterprise, including PLCs, SCADA systems, MES, and ERP, are treated as a "node" in an ecosystem. These nodes publish their data to the UNS, where it can be access and used by other nodes. This creates a seamless flow of information, eliminating the need for complex, individual connections between systems. Adding an inventory management system? Simply plug it into the UNS, and it can begin consuming the data it needs.
**What Does It Look Like?** The Unified Namespace uses a semantic hierarchy (as suggested in part 2 of the ISA-95 Standard) for structuring data and information. Starting from your Enterprise level, to Site, then Area, Line, and Cell. Organizing your UNS like this provides a common structure to all data, allowing anyone in the organization to be able to find what they need. ![](https://kajabi-storefronts-production.kajabi-cdn.com/kajabi-storefronts-production/file-uploads/blogs/27627/images/0ccb51-d8c2-544-7c8-406ead5bb234_UNS_Design.png) **Key Characteristics:** 1. **Single Source of Truth:** The UNS servers as the central repository of all data, ensuring consistency and reliability 2. **Real-Time Data Representation:** The UNS servers as a single-pane of glass for all data and information in a business, similar to how your smartphone serves as a single-pane of glass for all of human knowledge. 3. **Scalability and Flexibility:** With the UNS, adding new technologies and software becomes easier as they simply integrate in the existing Unified Namespace. 4. **Foundation for Advanced Applications:** The centralized data structure of the UNS is essential for applications like predictive analytics and real-time optimization #### Implementation Aspects: * Common IIoT protocols, such as [MQTT](/management-portal/designer/assets/data-connectors/mqtt) (Message Queuing Telemetry Transport) are often used to implement UNS, supporting efficient, scalable, and secure data exchange. * The UNS is flexible and can be integrated with various platforms that support necessary minimum technical requirements set by your organization, such as MQTT. * Every UNS should build and organized based on the [ISA-95 structure](/management-portal/designer/assets/asset-hierarchies/isa-95) #### Common Questions **1. Where Does the Unified Namespace Live?** * The Unified Namespace doesn't reside in a specific location or within a single piece of software. It's a conceptual framework that exists across the entire network of a business. The UNS is implemented through the integration of various systems, machines, and software applications, each contributing to and accessing the shared data pool. It's more about how data is structured and accessed across the network rather than a specific "place" where it lives **2. What Software Can Be Used to Build a Unified Namespace** * Building a Unified Namespace is flexible in terms of software choices, as long as the chosen platforms support the necessary minimum technical requirements of your business. Some popular software options include: * Tricloud Nexus * HighByte Intelligence Hub * Inductive Automation's Ignition * Tatsoft's FrameworX * and more * The above list is by no means exhaustive and the above 3 platforms should not be taken as the only options for UNS. Various IIoT platforms can be adapted to build a UNS, provided they support IIoT protocols and standards like MQTT. **3. Where Does History Get Stored in a Unified Namespace?** * Historical data is typically stored in databases and historians that are part of the overall network. These databases can be on-premises or cloud-based, depending on the business's needs. The UNS itself facilitates the collection and transfer of this data to the storage databases, but it's not the storage location. The key is that the historical data remains accessible and integrated within the UNS framework, allowing for efficient retrieval and analysis as needed. # Availability, Reliability & Performance * SLOs/SLAs, HA/DR, backup & restore * Scaling patterns (multi-site, multi-tenant, workload isolation) # Operations ## Operations The **Operations** section in Nexus is where you monitor and manage the operational state of your deployed devices and modules in real-time.\\ The Operations workspace is divided into two main areas: * **Monitoring** - Real-time insight into device status, module logs, and job history. * **Alarms** - Alerts and notifications for abnormal conditions, connectivity issues, or module errors.

Monitoring Page for a Device

*** ### Key Features The **Operations** page equips you with powerful capabilities to manage, monitor, and respond to events across your Nexus environment: * **Unified Device View** – Browse all connected devices, their deployed modules, and current operational status in one place * **Real-Time Monitoring** – See live updates of device health, job executions, and module activity * **Detailed Module Insights** – Access module logs, configuration twins, and data connector details for in-depth analysis * **Job Execution Tracking** – Review the full execution history of File Jobs, FTP Jobs, and File Share Jobs, including logs, file counts, and transfer sizes * **Direct Module Commands** – Invoke module functionality instantly using the Commands tab (for Nexus SDK-enabled modules) * **Centralized Alarm Management** – Monitor, filter, and acknowledge alarms across the entire environment * **Root Cause Analysis Tools** – Leverage logs, alarms, and historical job data to identify and address operational issues quickly * **Proactive Incident Response** – Detect abnormal patterns early and take action before they escalate into service disruptions *** ### Monitoring

Module Details Page

The **Monitoring** area allows you to drill down into each connected device and view detailed status information.\ From here, you can: * See the list of devices in your environment and their performance, CPU, Memory and Disk usage * Inspect all modules deployed to a specific device, and assess module performance CPU and Memory usage * Access module-specific tools, such as: * **Module Logs** – Detailed runtime logs for debugging and status tracking * **Twin View** – Compare Desired vs. Reported module configurations * **Commands** – Send real-time commands to modules (if Nexus SDK-enabled) * **Local Storage** - Browse local storage of the Edge device * **Data Connectors** – Browse remote filebased data connectors * **Jobs History** – View execution history for scheduled jobs. This is the main hub for **real-time operational control and troubleshooting**. *** ### Alarms

Alarms Page

The **Alarms** area centralizes all notifications for operational events that require your attention.\ Alarms are generated when Nexus detects conditions such as: * Device or module connectivity loss * Job failures or timeouts * Data transfer issues * Configuration mismatches From the Alarms page, you can: * View active and historical alarms * Acknowledge or clear alarms once addressed * Filter alarms by severity, device, or time period * Use alarm details to diagnose root causes quickly This ensures that operational teams can react promptly and effectively to any disruptions in the system. *** ### Typical Use Cases The Operations section is essential for: * **Day-to-Day Device Monitoring** – Keeping an eye on field-deployed devices and ensuring they are operating as expected * **Troubleshooting Issues** – Quickly identifying and resolving operational problems * **Job and Data Flow Validation** – Confirming that scheduled jobs are running successfully and data is moving as intended * **Incident Response** – Using alarms to detect and respond to critical situations # Monitoring The **Monitoring** tab in the Nexus Management Portal provides operators with a real-time view of individual device health, performance metrics, and module-level status. This interface is essential for diagnosing issues, understanding resource utilization, and verifying data pipeline activity. ## Monitoring UI Overview

Showing Monitoring device page

The **Monitoring** interface is organized into two main areas; Device/Module Tree and Details View for the selected Device or Module. *** ### Device/Module Tree (Left Panel) The **Device/Module Tree** provides a hierarchical view of the monitored environment: * **Management Endpoints** act as the top-level grouping. Devices are organized under the endpoints to which they have been provisioned. * **Devices** appear as child nodes under each management endpoint, and can represent either an edge device or a standard IoT device, that does not have edge capabilities. * **Modules** are shown under each device, representing the individual runtime components deployed to that device. You can select any node in the tree—management endpoint, device, or module—to inspect detailed information in the right-hand pane. > Tip: Use the **filter bar** above the tree to quickly locate specific devices or modules by name. > ⚙️ **Edge Devices vs. Standard IoT Devices** > > The Monitoring UI will automatically adapt to the capabilities of the selected device type. > > * **Edge Devices** run a local runtime and support advanced features such as **module deployment and lifecycle management** and **detailed monitoring**. > * **Edge Devices with Nexus SDK** are devices that are implemented using the Nexus SDK. This enables additional capabilities, such as **streaming logs**, executing module level custom **commands** and real-time visibility into **data collection** activities. > * **Standard IoT Devices** are typically more constrained and support only **basic monitoring** (e.g., connectivity status and limited telemetry). They do not support module deployment. > > 💡 The Monitoring UI dynamically adapts to each device’s capabilities—displaying only the features supported by the selected device. *** ### Details View (Right Panel) The **Details View** dynamically updates to reflect the entity currently selected in the Device Tree: * When a **management endpoint** is selected, the view provides an overview of that endpoint’s devices. * When a **device** is selected, the view shows comprehensive real-time monitoring data, including health status, metrics, deployed modules, data connectors, and reported issues. * When a **module** is selected, the view displays module-specific diagnostics, such as runtime status, errors, version information, and connection state (if applicable). This split-view layout allows operators to quickly navigate between devices and their components while maintaining context for both hierarchical structure and individual status.

Module Details frontpage

Each Device Tree node type is described in the following subpages. # Device Details When selecting a **device**, the Details View displays a comprehensive snapshot of the device’s current state.

Device Detail Page

### **Tool bar** * **Ping device**\ Button that verifies if the device is online, by sending a message and awaiting a response. * **Device Configuration**\ A shortcut to the device configuration page, where assets, applications and modules can be assigned. * **Refresh**\ Performs a forced refresh of all information on the page, by getting information directly from the management endpoint, where the device is provisioned. *** ### **Connectivity Status** This section displays the latest connection status between the device and its assigned management endpoint. It includes: * **Connection State**\ Indicates whether the device is currently **connected** or **disconnected** based on its heartbeat activity. * **Last Seen**\ Timestamp of the most recent successful communication from the device (e.g., telemetry or ping). * **Last Ping Attempt** and **Last Successful Ping**\ Results of the platform’s automated connectivity checks. These values help diagnose intermittent or persistent connectivity issues. * **Uptime** *(if **Nexus DeviceMonitoring** is deployed to the device)*\ Shows the duration since the device was last restarted, providing insight into runtime stability. *** ### **Resource Metrics** This section provides time-series visualizations of the device’s system resource usage, given that the module supports the Nexus SDK. These metrics are collected and reported by the module if it is built using the **Nexus SDK**. The charts help operators monitor resource consumption trends and identify performance bottlenecks, such as memory leaks or disk exhaustion. Metrics include: * **CPU Utilization (P99)**\ Displays the 99th percentile of CPU usage over time, highlighting peak load behavior rather than average usage. This is useful for identifying resource spikes and understanding worst-case performance. * **Memory Usage**\ Shows both **used** and **total** memory (in gigabytes), allowing you to assess how much RAM is available and whether the device is under memory pressure. * **Disk Usage**\ Visualizes available disk space as a percentage of the total storage capacity. This helps detect devices approaching storage limits, which could impact data collection or module stability. > 📊 These charts support configurable time windows, making it easier to correlate resource usage with recent events or issues. *** ### **Modules** The **Modules** section provides a detailed overview of all modules deployed to the selected device. For each module, the platform displays module name, version, current status, restart count and any reported errors. This view helps operators validate module health, detect misconfigurations, and monitor deployment activity in real time. \ **Module Lifecycle States** Each module reports one of the following lifecycle states: * **Starting**\ The module has been declared in the desired deployment configuration, but the device has not yet reported its status. This typically occurs just after deployment and indicates that the module is being downloaded from the container registry and started up. * **Running**\ The module is actively running and has reported a healthy state. This is the expected status during normal operation. * **Error**\ The module has encountered a critical runtime error. This may result from a failed start-up, crash, misconfiguration, or dependency failure. A descriptive error messages (e.g., exit code) is shown, when available. Clicking the module state redirects to the module logs. * **Warning**\ The module is running, but with non-critical issues. Examples include configuration issues or warnings emitted by the module runtime. These are useful for early detection of underlying problems. A descriptive error messages (e.g., exit code) is shown, when available. * **Stopping**\ The module is still being reported by the device, but it is no longer part of the desired deployment configuration. This indicates the module is in the process of being stopped or cleaned up. *** ### **Data Connectors** The **Data Connectors** section provides visibility into the status of data collection modules deployed to the device. This feature is available only if the data collection modules are built using the **Nexus Device SDK**, which enables reporting of internal state and connection health. Each row in the list represents a **data collector module** currently deployed to the device. **Expandable View** * Each module line can be **expanded** to show a list of **endpoints**. * Endpoints represent the individual data sources or connections managed by the module. > 🔍 **Note:** *The definition of an "endpoint" depends on the protocol or data source type. For example:* > > OPC UA: *Each endpoint corresponds to a different **OPC UA server***\ > *MQTT: Each endpoint corresponds to a subscribed **topic***\ > \&#xNAN;*Modbus: Each endpoint represents a **slave device***\ > \&#xNAN;*The **DataDistribution** module hosts formula-based calculations, which is also treated as a data collectors with an endpoint.* **Endpoint Details** For each endpoint, the following details are shown: * **Endpoint Name**\ A unique identifier representing the connection or source. * **State**\ The current operational state of the endpoint, such as: * **Stopped** – data collection is deactivated * **Running** – data is being collected successfully * **Reconnecting** – endpoint is temporarily disconnected * **Failure** – data collection has failed or configuration is invalid * **Details**\ Additional status information for error messages. This granularity allows operators to quickly pinpoint which part of the data pipeline is experiencing issues, even when a module is connected to multiple sources. *** ### **Issues** The **Issues** section displays real-time problems detected by the **DeviceMonitoring** module. This feature is only available on devices where **DeviceMonitoring** is **deployed and running**. Each issue represents a system-level condition that may impact device performance, stability, or data integrity. When an issue is detected, it is automatically logged in the UI and also triggers an **alarm** in the platform’s alerting system, allowing for immediate visibility and response. **Available Issue Types** Issues are primarily related to resource constraints and internal device health: * **CPU Usage Over Limit**\ Triggered when the device’s CPU usage exceeds a defined threshold for a sustained period. * **Memory Under Limit**\ Reported when available memory falls below a safe operating threshold, indicating possible memory exhaustion. * **Disk Space Under Limit**\ Indicates that remaining disk space is too low to ensure stable operation or continued data collection. * **Inter-Module Communication Queue Count Too Large**\ Occurs when internal message queues between modules exceed expected limits, potentially pointing to issues on processing or bottlenecks. **Issue Details** Each issue entry includes: * **Timestamp**\ The exact time the condition was first detected. This helps correlate issues with events such as deployments, spikes in telemetry, or resource saturation. * **Description**\ A detailed explanation of the issue, including measured values and thresholds. For example:\ \&#xNAN;*“CPU usage at 97.3%, exceeding threshold of 85%”* > ⚠️ Issues are continuously monitored. When the underlying condition clears (e.g., resource usage returns to normal), the corresponding platform alarm is automatically set to RTN (Return To Normal). The operator still needs to acknowledge the alarm. # Properties The **Properties** tab provides static information about the selected device. This includes identification details, platform specifications, and how the device is managed within the Nexus ecosystem.

The Properties Tab for a Device

### **Device Information** Basic identity and connection details: * **Name**\ The unique identifier of the device within the platform. * **Connection State**\ Indicates whether the device is currently connected or disconnected. * **Device Type**\ Specifies whether the device is a **Standard IoT Device** or an **Edge Device**. * **Authentication Method**\ Shows the method used to authenticate the device with the platform: * **Certificate-based (X.509)** * **Key-based (Shared Access Signature)** *** ### **Platform Information** Details about the underlying hardware and software environment: * **Platform OS**\ The operating system running on the device (e.g., Linux, Windows, RTOS). * **Platform Architecture**\ The processor architecture (e.g., `x64`, `arm32`, `arm64`). * **Runtime Version**\ The version of the IoT Edge Runtime installed on the device. *** ### **Management Endpoint** Describes how the device is grouped and managed: * **Name**\ The name of the management endpoint to which the device is assigned. * **Location**\ A user-defined or system-defined label representing the physical or logical location of the endpoint # Deployments ### Deployments The **Deployments** tab shows the full history of deployments made to the selected device. Each deployment represents a versioned configuration, including assigned modules and settings delivered to the device via the management platform. The left panel displays a paginated, searchable list of past deployments.

Device Deployments Tab

**Columns include:** * **Date**\ The timestamp when the deployment was initiated. * **Name**\ A descriptive label for the deployment (e.g., “Deployment of tc-edge-local-02”). * **Status**\ Final result of the deployment process: * **Completed** – Deployment finished successfully and was applied to the device. * **Cancelled** – Deployment was intentionally aborted or never finalized. * **Failed** – Deployment encountered an error and did not complete. * **Created By**\ The user who initiated the deployment. > 🔄 Use the **Refresh** button to update the deployment list and **Redeploy** to redeploy the selected deployment. *** ### **Deployment Details** When a deployment is selected, the right panel shows detailed metadata: * **Deployment Name**\ The full name of the deployment operation. * **Status**\ Final deployment result. * **Target Device**\ The name of the device that is deployed to. * **Device Configuration Version**\ The version number of the device configuration, that has been applied to the device. * **Created**\ Timestamp for when the deployment was initiated. * **Last Updated**\ Timestamp for when the deployment was last modified. * **Created By**\ The user who triggered the deployment. * **Description**\ Human-readable explanation of what was deployed (e.g., version details, changes). * **Duration**\ Total time taken for the deployment to complete. *** ### **Events** A chronological timeline of deployment-related events, shown at the bottom of the details panel. This section is used for debugging failed deployments, and for confirming the progress and results of successful ones. * **Timestamp**\ Time of the event. * **Type**\ Classification (e.g., *Started,* *Information*, *Warning*, *Failed, Completed*). * **Description**\ Detailed event message explaining what occurred during the deployment (e.g., module started, configuration applied). # Module Details When a module is selected in the **Device Tree**, the Monitoring UI displays detailed runtime and configuration information for that module. This view helps understand how a specific module is operating, how it was deployed, and whether it supports advanced features like logging, command execution or other functionality. The module details page has different tabs. The default tab is the "**Information**" page, which contains information about the module and its current performance.

Module Details Page

### **Tool bar** * **Restart Module**\ Button that Restarts the selected module. This might be handy for debugging of incidents, to enable tracing of module behaviour upon startup using eg. Logs. * **Refresh**\ Performs a forced refresh of all information on the module page *** ### **Module Information** This section displays core runtime metadata and capabilities: * **Module Name**\ The name of the module instance deployed to the device. * **Restart Policy**\ Defines how the module is restarted by the runtime in case of failure or manual stop: * `always`: automatically restarts on exit * `on-failure`: restarts only on non-zero exit * `never`: does not restart automatically * **Nexus SDK Supported**\ Indicates whether the module is built using the **Nexus Device SDK**. If `True`, additional features such as **log streaming** and **remote command execution** are available. * **Runtime Status**\ The current operational state of the module (e.g., `running`, `stopped`, `error`). *** ### **Module Container** Describes the container image used to run the module: * **Image URI**\ The full registry path of the container image (e.g., `mcr.microsoft.com/azure-blob-storage:1.4`). * **Version**\ The version tag of the image. * **Image Type**\ The containerization technology used. Currently only Docker-compatible is supported. * **Image Pull Policy**\ Defines when the image is pulled from the registry: * `always`: always pull the latest version * `on-create`: pull only when the module is created * `if-not-present`: pull only if the image is not already cached on the device *** ### **Module Lifecycle** Provides information related to the module’s operation: * **Last Start Time**\ The most recent time the module was started. * **Last Restart Time**\ The last time the module was automatically or manually restarted. * **Last Exit Time**\ When the module last stopped running (due to completion, crash, or restart). * **Last Exit Code**\ The exit code from the most recent module shutdown. This is useful for diagnosing abnormal terminations. *** ### **Resource Metrics** This section provides time-series visualizations of the module's system resource usage, given that the module supports the Nexus SDK. These metrics are collected and reported by the module if it is built using the **Nexus SDK**. The charts help operators monitor system resources as trends to identify performance bottlenecks, such as memory leaks or CPU overload. Metrics include: * **CPU Utilization (P99)**\ Displays the 99th percentile of CPU usage over time, highlighting peak load behavior rather than average usage. This is useful for identifying resource spikes and understanding worst-case performance. * **Memory Usage**\ Shows both **used** and **total** memory (in gigabytes), allowing you to assess how much RAM is available and whether the device is under memory pressure. > 📊 These charts support configurable time windows, making it easier to correlate resource usage with recent events or issues. # Module Log The **Module Log** tab provides insight into the logs generated by the selected module. The available logging features depend on the module’s implementation and capabilities. If the module is built using the **Nexus Device SDK**, it supports **structured historical logging** as well as **real-time log streaming** from the device to the platform. For modules that do not use the SDK, basic console output may still be available.

Module Log tab of a Selected Module

The tab is divided into two views: * **Historical Log**\ Displays a paginated list of structured log entries collected from the module. This view is available **only for modules that support the Nexus SDK**, and allows filtering, searching, and expanding log entries for full detail as well as real-time streaming of logs directly from the Module to the browser. * **Console Log**\ Streams the last 300 Log lines of standard output and error messages from the module container, if supported by the device runtime. This view provides basic runtime visibility even for non-SDK modules. > 💡 When SDK-based logging is available, the platform enables advanced features such as log-level filtering, grouping, and live updates. {% hint style="info" %} As default, Logs are send from the Module with a 5 minute interval. If Logs doesnt appear right away, please wait a few minutes, and refresh the historical view or enable the Live Stream Log radio button. This forces the device to stream the logs directly to the Browser in real-time. Alternatively you can always use the Console Logs, which immidiatly retrieves and displays the last 300 Log Lines from the Module. {% endhint %} *** ### Historical Log The **Historical Log** view displays a structured, paginated list of recent log messages emitted by the selected module. Each entry includes metadata to support efficient filtering, sorting, and analysis. **Tool Bar** The historical Log has a toolbar in the top of the page

Historical Log Toolbar

* **Module Log Level Setting**\ This setting is available for all modules utilizing the Nexus SDK. It allows you to control the log output by specifying a log level filter, determining the severity of logs that the module should send * *Default Setting* The default log level is set to 'Error', meaning only error messages will be sent * *Verbose Setting* the log level to 'Verbose' enables the module to send all logs regardless of severity. This includes debug, informational, warning and error messages Use this setting to customize logging behavior based on your monitoring and debugging needs * **Live Stream Log**\ When enabled, new log messages are streamed in real-time into the table without requiring manual refresh. It is a good idea to order the log table on the Timestamp column, so the most recent streamed logs are shown in top * **Refresh**\ Reloads the log list to show the most recent entries * **Search Field**\ Allows filtering logs by message content. **Log Table** The Log Table shows each Log item (Log Line). The Table has 3 columns, that can be ordered and it supports grouping of colums as well.

Live Streaming of Module Log

1. **Timestamp**\ The exact time the log entry was generated, useful for correlating events across modules and devices. 2. **Level**\ The severity of the message, such as: * `Information` * `Warning` * `Error` * `Debug` * `Verbose` > 💡 *Log verbosity is configurable via the **Module Log Level** Setting dropdown.* 3. **Message**\ A short summary of the log event (e.g., `JobEnded`, `DeviceConnectionStateChanged`, `Synchronizing Cold Path Measurements`). > ➕ Clicking the **plus icon** to the left of a log entry expands the row to show full log details, such as structured data or stack traces (if provided). *** ### Console Log The **Console Log** view provides a real-time snapshot of unstructured text output from the module’s standard output (stdout) and standard error (stderr) streams. This view is useful for live debugging or observing the raw behavior of the module as it runs.

Showing Console Log for a Custom Module (NodeRED)

Unlike the **Historical Log**, which shows structured, indexed entries (available only for Nexus SDK-enabled modules), the Console Log presents raw line-based output similar to traditional terminal logs. **Features and Controls** * **Scroll to Bottom**\ When enabled, the log view automatically scrolls to show the most recent messages, ensuring you’re always seeing the latest output. * **Auto Refresh**\ Automatically maintains the connection and updates the stream, even if new content is arriving rapidly. * **Refresh Button**\ Manually reloads the log output from the current module container. # Twin ## Module Twin Page The **Module Twin** page provides a side-by-side view of the module’s **Desired Twin State** and **Reported Twin State**. \ This page is used for monitoring and adjusting the runtime configuration of a deployed module.

Showing Module Twin (Module Configuration)

*** ### **What is Module Twin?** The **Module Twin** is a JSON-based digital representation of a module’s configuration and runtime state on an Edge device. {% hint style="warning" %} Module Twins are used my Modules that uses the Nexus SDK or 3rd party Modules that supports Azure IoT Edge. For other 3rd party modules, the Module Twin will **not** be used to configure the Module, as these Modules most often uses Environment Variables or Files for configuration. {% endhint %} Module Twins contains two key parts: * **Desired Twin State** – The configuration you *want* the module to have * **Reported Twin State** – The configuration the module *actually* has applied and is currently running with

Module Twin Example

The Desired Twin acts as the *target configuration* that the platform sends to the module, while the Reported Twin is the *real-time feedback* from the module back to the platform. By comparing the two, you can verify whether the configuration was applied successfully. This Twin mechanism allows the platform and Edge modules to stay synchronized and makes it possible to: * Remotely configure modules that is allready running on an Edge device, without having to login on the device * Rapidly Verify applied configurations, or impact of trying out different configuration for the module * Debug and temporarily override settings without redeploying the full Asset Hierarchy {% hint style="info" %} You can change the Desired Twin of a Module at any time. However as soon as a redployment to the device is done, the Desired Twin may be overwritten with a new configuration. It is recommended to change the Desired Twin for debugging and testing purposes. {% endhint %} ### **Desired Twin State** The Desired Twin represents the configuration settings that you want the module to run with.\ This is the **target configuration** that the IoT Hub sends to the device. You can edit the Desired Twin directly in the interface: 1. Make changes to the JSON structure in the **Desired state** editor (left side). 2. Click **Save** to send the updated Desired Twin to the device. 3. The module will apply the new configuration without needing a full redeployment. **Important:** Any manual changes made here will be **overwritten** if a new deployment is made to the device. This means editing the Desired Twin should primarily be used for: * Debugging purposes * Rapid testing of configuration changes *** ### **Reported Twin State** The Reported Twin (right side) is the module’s actual current configuration as reported by the device.\ This shows the **applied state** after the module has processed and implemented the Desired Twin. It also shows the exact timestamp a Json property has been applied to the configuration. *** ### **Updating and Verifying Twins** After making changes to the Desired Twin: 1. Click **Save**. 2. Wait for the module to apply the configuration. 3. Click the **Refresh** button to re-fetch both the Desired and Reported Twin states from the device. This is useful when verifying if a recent change to the Desired Twin has been applied successfully. 4. Confirm that the **Reported State** matches the Desired State. If there’s a mismatch, it could indicate: * The module hasn’t yet synchronized. * There’s an error preventing the new configuration from applying. In this case you can check the [Module Log](/management-portal/operations/monitoring/module-details/module-log) for any warning or errors that may have occurred when applying the desired state. It is recommended to use the Console Log for this. #### **Differences View** You can click the **Differences** button to highlight changes between the Desired Twin and the Reported Twin.\ This makes it easier to spot discrepancies in configuration. *** ### **Use Cases of Module Twin** The Module Twin page is especially useful in scenarios where quick configuration changes or troubleshooting is required. Some common use cases include: * **Rapid configuration testing**\ When you need to try different parameter values (e.g., log level, polling intervals, or protocol settings) without creating and deploying a new version of the asset hierarchy. * **Debugging and issue resolution**\ If a module is not behaving as expected, you can adjust settings in the Desired Twin, apply them immediately, and observe changes in real time. * **Verifying deployment success**\ After deploying a module, use the Twin page to confirm that the Reported Twin matches the Desired Twin, ensuring the configuration was applied correctly. * **Temporary overrides**\ In situations where a quick fix is needed - such as pointing to a test broker or alternate data source -you can change the Desired Twin for short-term operation, then revert later. * **Performance tuning**\ Adjust settings like buffer sizes, batching thresholds, or retry intervals on the fly to find optimal performance parameters. # Commands \ The **Commands** tab of a Module, provides a direct way to invoke specific functionality on a module without requiring a re-deployment. \ Think of the Commands Tab as an **interactive API testing console** built into the Nexus interface - allowing you to send JSON payloads to the module and receive immediate responses.

Showing the Commands page/tab for the FileTranferModule

{% hint style="info" %} The **Commands** tab is only available for modules that support the **Nexus SDK** {% endhint %} *** ### Key UI Elements * **Command Drop-down** - Lists all available commands for the selected module * **Refresh** – Updates the list of commands in case new ones are exposed * **Show Schema** – Displays the JSON Schema defining the exact structure of the required payload * **Payload Field** – A text editor where you insert the JSON payload that will be sent to the module * **Send Payload** – Executes the selected command with the provided payload * **Response Panel** – Displays the response returned by the module *** ### How It Works When a module is developed with the Nexus SDK, its developer can **expose one or more commands**.\ These commands become available in the **Commands** tab for that module. From here, you can: 1. Select a command from the **Command** drop-down menu. 2. (Optional) Click **Show Schema** to see the JSON Schema for the expected payload format.

Showing Json Schema for the ListBlobs Command of the FileTransferModule

3. Enter/Fill out the JSON payload in the **Payload** section

Enter the expected Json payload based on the Schema

4. Click **Send Payload** to execute the command on the module 5. View the **Response** in the right-hand panel

Showing the Response from sending the Payload to the Command

*** ### Use Cases The Commands tab is particularly useful for: * **Debugging and Troubleshooting** – Test module behavior with different inputs to identify and resolve issues quickly. * **Rapid Iteration** – Try different configurations or trigger specific actions without a full redeployment. * **Operational Tasks** – Manually invoke data synchronization, file listing, or other module-specific functions. *** ### Important Notes * Only modules developed with the **Nexus SDK** will expose commands in this tab * Payloads must strictly follow the JSON Schema format provided by **Show Schema** * Incorrect payload formatting can result in command execution errors * Changes made through commands are **runtime actions** - they do not permanently alter the module configuration unless the module is designed to store state # File Browsing on Edge ## File Browsing on Edge device local Storage The **File Browsing** feature in Tricloud Nexus allows you to explore and manage files stored on your Edge device’s local storage account. This is useful for viewing module-generated files, configuration data, logs, or any other files stored locally at the Edge. The browsing functionality is available for the **`localblobstorage`** module, which is part of the standard device installation. *** ### What is `localblobstorage`? The `localblobstorage` module provides a **local storage account** on the Edge device.\ It allows modules to: * **Store files locally** on the device for immediate or later use. * **Stage files for cloud upload** so that they are automatically transferred to cloud storage when a network connection becomes available. * **Organize data into containers** (similar to folders or directories) for better file management. *** ### Navigating to File Browsing

Browsing Files stored on Edge Device

1. Go to **Monitoring** in the left-hand menu. 2. In the **Devices tree**, expand the devices and select the device you want to inspect. Select the **`localblobstorage`** module. 3. Open the **Browse Edge Storage** tab. 4. From the **Container** dropdown, select the container you want to explore (e.g., `config`, `data`, `logs`). ***

Browsing the 'config' container

### Browsing Local Edge Files The file browser displays: * **Folder structure** for the selected container. * **Files and subfolders** with details such as: * **Name** * **Date Created** * **File Size** * **File preview panel** showing: * File type * Size * Creation and modification timestamps You can toggle **View Details** to see metadata for the selected file, or use the **Search** bar to quickly locate files. {% hint style="info" %} You can right-click on a file that lets you rename or delete the file. Downloading the file directly from Edge is currently not supported, however this can be achieved using the filetransfermodule using a custom command. {% endhint %} *** ### Typical Use Cases * **Checking exsistance of configuration files** (e.g., `dynamicconfig.json`, `mode.txt`, `version.txt`). * **Delete old or corrupt files** from the Edge device, that should no longer be there * **Viewing locally cached data** before it is uploaded to the cloud. * **Verifying module output files** generated by Edge processing. * **Debugging** by accessing files stored locally at edge # Browse Remote Filebased Data Connections ## Browse Remote Filebased Data Connections The **Browse Remote Filebased Data Connections** feature allows you to test and explore any file-based data connection configured within your Asset Hierarchy. If you have configured an **FTP Server** or **File Share** within the Asset Hierarchy and deployed the hierarchy to a device, the **FileTransferModule** will be deployed to that device. This module enables the Edge device to directly connect to the remote system, listing the available folders and files it can access. ***

Browsing a files on a remote FTP Server

### Accessing the Feature 1. In the **Monitoring** section, navigate to the **Devices** tree 2. Select the target device 3. Choose the **FileTransferModule** from the module list 4. Select the **Browse Data Connectors** tab 5. Choose whether to browse a configured **FTP Server** or **File Share** 6. The Edge device will **try to connect** to the r**emote file based data connection**, to retrieve files and folders {% hint style="info" %} Make sure you have **configured** and **deployed** at least one [FTP Server Data Connector](/management-portal/designer/assets/data-connectors/ftp-server) or one [File share data connector,](/management-portal/designer/assets/data-connectors/file-share) otherwise the FileTransferModule may not be deployed on the device. {% endhint %} *** ### Browsing Remote Storage Once a data connector is selected, the file browser will display the directory structure and available files directly from the remote system. * **FTP Servers** – Lists folders and files available via an FTP, FTPS, or SFTP connection

Browsing a files on a remote FTP Server

* **File Shares** – Lists folders and files available from an SMB/CIFS-compatible network share

Browsing a files on a remote File Share

*** ### Key Points * The **Edge device** initiates the connection to the remote server or share—no files are transferred unless explicitly done via a job or manual action. * The browsing interface is similar to [File Browsing on Edge](/management-portal/operations/monitoring/module-details/file-browsing-on-edge), including: * Folder navigation * File list view and details pane * Sorting and search capabilities * This functionality is ideal for **verifying credentials, connectivity, and file availability** before setting up automated file transfer jobs. *** ### Example Use Cases * **Troubleshoot access** issues by testing the remote connection directly from the deployed Edge device, to identify connectivity issues such as firewall, IP address, DNS name resolving etc. * **Confirm** that an FTP server **contains** the expected report **files** before configuring an [**FTP Job**](/management-portal/designer/assets/jobs/ftp-job) * **Verify** the **directory structure** of a lab’s file share to correctly target **file patterns** in a [**File Share Job**](/management-portal/designer/assets/jobs/file-share-job) # Jobs History ## Jobs History The **Jobs History** page is your central logbook for all automated file transfer activities executed by your devices. Every time a job runs - whether it’s moving files locally, retrieving them from an FTP server, or importing from a file share - it leaves a detailed record here. This history is essential for monitoring operational health, verifying that data pipelines are functioning as intended, and diagnosing issues when they occur. By combining a high-level job overview with in-depth execution logs, the **Jobs History** page allows you to quickly spot trends, confirm successful transfers, and troubleshoot failed runs - all in one place. Whether you’re ensuring that scheduled jobs keep your data flowing or investigating why a particular file didn’t arrive, this is the go-to location for understanding what happened, when it happened, and why. *** ### Jobs History The **Jobs History** page provides a complete overview of file transfer jobs that have been executed on a device. These jobs can include: * [**File Jobs**](/management-portal/designer/assets/jobs/file-job) * [**FTP Jobs**](/management-portal/designer/assets/jobs/ftp-job) * [**File Share Jobs**](/management-portal/designer/assets/jobs/file-share-job) Jobs will appear on this page if they have been configured from an **Asset Hierarchy** and that hierarchy has been deployed to a device. *** ### Acessing Jobs History If an **FTP Job, File Share Job** **or File Job** is configured in the Asset Hierarchy and deployed to the device, the **FileTransferModule** will be installed on the device.

Accessing the Jobs History via the FileTransferModule

1. Navigate to the **Monitoring** section 2. Select the target device from the device tree 3. Open the **FileTransferModule** 4. Click the **Jobs History** tab {% hint style="info" %} Make sure you have **configured** and **deployed** at least one [File Job](/management-portal/designer/assets/jobs/file-job), [FTP Job](/management-portal/designer/assets/jobs/ftp-job) or [File Share Job](/management-portal/designer/assets/jobs/file-share-job) in an Asset Hierarchy[,](/management-portal/designer/assets/data-connectors/file-share) otherwise the FileTransferModule may not be deployed on the device. {% endhint %} *** ### Filtering & Searching in Job Executions From the **Jobs History** page, you can: * **Filter by Job Type** – Show all jobs, only File Jobs, FTP Jobs, or File Share Jobs * **Filter by Time Range** – Limit results to the last 24 hours, last 7 days, or a custom date range * **Search** – Use free-text search to find specific jobs or errors (e.g., search for *Error* or *Timeout*)

Displaying Job Executions (Top Table), and Detailed Job Execution Log (Bottom Table)

### Job Execution List (Top Table) The top table lists all job runs that match your filters, showing: * **State** – Whether the job completed successfully or failed * **Start Time** – When the job started * **Duration** – How long the job took to complete * **Job Name** – The configured name of the job * **Config ID** – The specific data connector used for the job * **Type** – File job, FTP job, or file share job * **Files Transferred** – Number of files moved/copied/deleted in this execution * **MB Transferred** – Total size of transferred data in megabytes * **Device** – The device where the job was executed *** ### Detailed Job Execution Log (Bottom Table) When you select a job from the list, detailed log entries appear in the bottom table.\ These logs show: * Connection attempts and successes * File matching patterns * Download/upload progress * Errors and warnings (if any) *** ### Use Cases The **Jobs History** feature can be used to: * **Validate** that jobs are running on schedule and transferring the expected files. * **Debug** jobs that fail due to connectivity issues, authentication errors, or file matching problems * **Audit** historical transfer data for troubleshooting and compliance purposes # Management Endpoint Details ### Management Endpoints Management Endpoints represent the logical gateways under which devices are organized and managed. > ℹ️ **Note:** Detailed views for Management Endpoints are not yet implemented. This functionality will be added in a future version of the platform. # Alarms This section describes what an alarm is within the Nexus platform and outlines the key properties that describe each alarm instance, including a description of its lifecycle. An **alarm** in the Nexus platform represents a system-detected condition that requires attention. Alarms are raised by the Device Monitoring component in the Nexus platform, when anomalies are detected. For example when monitored values exceed defined thresholds, communication fails, or system errors occur. Alarms are persistent entities with rich metadata to support tracking, filtering, and resolution across the entire platform. Each alarm includes a set of core properties that uniquely identify it, describe its origin, and determine its importance. These properties also defines the *state* of the alarm—those are covered in the separate Alarm Lifecycle section.

Alarms can be found in the Monitoring section of the main menu

*** ## Alarm Properties
PropertyDescription
Id

A globally unique identifier for the alarm, also used as a human-readable name. This format ensures that alarms are uniquely traceable across distributed systems.

It is structured as:

{device id}.{property}

AreaA logical grouping that describes the source context of the alarm. Typically set to Device, but can also represent broader scopes such as a customer, system group, or hierarchical structure.
TimeOnThe UTC timestamp when the alarm was first triggered (entered the alarm state). This marks the beginning of the current alarm incident.
TimeOffThe UTC timestamp when the alarm condition returned to normal. If this value is null, the alarm is still active.
SourceIndicates the component type where the alarm originated. This could be a module on an edge device, a data connector, or a backend service.
SourceReference

A detailed path to the specific origin of the alarm. For example:{management endpoint name}/{device id}/{module id}

This reference is used for correlation and root-cause analysis.

PriorityA numeric indicator of the alarm's severity. Lower values indicate higher criticality (e.g., 1 = critical, 999 = low priority). Priority helps operators sort and triage alarms based on operational impact.
These properties enable precise filtering, auditing, and escalation, ensuring that each alarm is actionable and traceable within its operational context. # Alarm List The Alarms page helps operators and system administrators quickly identify active issues, assess their impact, and take corrective actions. *** ### Alarms List The **Alarms** list in the Nexus Platform provides a real-time overview of all *standing alarms -* that is, alarms that are currently active or have returned to normal but have not yet been acknowledged.

Screenshot from Alarms in the Nexus Platform

*** ### Layout and Functionality The interface is structured as a sortable table with interactive controls that enhance usability and filtering. Each row in the table represents a single alarm instance with core information visible at a glance. Alarms can be expanded to reveal additional metadata and context.

Expanded alarm, where additional properties are visible

*** ### Toolbar Actions The toolbar above the table includes several utility buttons:

Alarm user interface buttons

ButtonFunction

Acknowledge

Alarm

Selecting one or more alarms enables the "Acknowledge Alarm" button. This acknowledges the alarms, indicating that the operator is aware of the condition and has taken responsibility for addressing it. Upon acknowledgment, the alarms are enriched with the operator’s name and the timestamp of the action. The operator may also include an optional comment to provide context, describe the intended mitigation, or document observations related to the alarm.

Suppress

Alarms

Allows selected alarms to be temporarily hidden from the view. Useful during maintenance windows or known transient conditions. Suppressed alarms are not deleted and will reappear once suppression ends. The suppression of alarms is based on logical filters.

Reset

View

Clears all filters, sorting, and expanded rows to restore the default table layout.

Alarms

History

Opens a historical view of all alarm state changes. This view includes alarms that are no longer standing but may be relevant for audit or troubleshooting.
RefreshManually refreshes the alarm list to fetch the latest state.
# Alarm Lifecycle The Nexus Platform alarm management system adheres to the ANSI/ISA-18 standard for alarm management. This standard defines a lifecycle for alarm states to ensure consistent handling, visibility, and operator response. Each alarm follows a well-defined sequence of states from activation to resolution, enabling operators to track both the current status and the history of an alarmed condition. Understanding this lifecycle is essential for effective alarm handling, acknowledgment workflows, and system reliability. *** ## Alarm States Each alarm follows a four-state model:
Alarm stateAcknowledgedDescription
IN ALARMNOT ACKNOWLEDGEDA condition has entered an alarm state and has not yet been acknowledged by an operator.
IN ALARMACKNOWLEDGEDThe alarm condition is still active, but has been acknowledged by an operator.
NORMALNOT ACKNOWLEDGEDThe condition has returned to normal, but the alarm has not yet been acknowledged by an operator.
NORMALACKNOWLEDGEDThe alarm condition has cleared and has been acknowledged. The alarm is considered resolved.
*** ## Alarm Transitioning State Model The alarm lifecycle and its transitions are illustrated below:

Transitions between alarm states

These states are visually represented in the UI using color-coded labels and badges. *** ## Acknowledgement of Alarms Initially, all alarms are in the **Normal Acknowledged** state (`RTNxACK`). This state indicates that the alarm is not currently active and has not been active since it was last acknowledged by an operator. In this state, the alarm is not visible in the alarm list. When an alarm condition occurs, the state moves to the Alarm Unacknowledged state (`ALARMxUNACK )` making is visible in the alarm list.

Active alarm, that has not been acknowledged

From here, the alarm condition can either disappear, moving to state (`RTNxUNACK`) or the operator can acknowledge the alarm, moving to state (`ALARMxACK`).

Example of unacknowledged alarm returning to normal, and active alarm that is acknowledged.

# Standard Platform Alarms The monitoring system in the Nexus platform includes a predefined set of alarms that detect abnormal operating conditions across edge devices, system modules, and data connectors. These alarms serve as early indicators of potential failures, performance degradation, or configuration errors, enabling operators to identify and address issues proactively. *** ## Overview of Alarms
Alarm NameDescription
Data Connector StateRaised when a data connector enters an error state or loses connection.
Data Connector Endpoint StateIndicates that the external system or endpoint associated with the connector is unreachable.
Module DisconnectedTriggers if a module fails to send heartbeat or telemetry for over 30 minutes.
Module Configuration AlarmRaised when there are issues validating or applying configuration settings.
Blob Storage AlarmIndicates issues with local blob storage, such as failed write operations or space limits.
Edge Agent Runtime AlarmRaised when the Edge Agent reports unhealthy status or runtime issues.
Edge Hub Runtime AlarmRaised when the Edge Hub is non-operational or reports errors in message routing.
Module Low Memory *)Triggered when a module's available memory falls below a defined threshold.
Module High CPU *)Raised when a module consistently consumes high CPU resources.
Device Low Disk Space Available *)Indicates that the device's available disk space is critically low.
Module Communication Queue Size *)Warns of growing message queues within a module, indicating backpressure or downstream issues.
Certain alarms require that **Device Monitoring** functionality is active on the device. This is achieved by deploying the `DeviceMonitoring` module, which periodically collects health and performance metrics from both the host system and the deployed modules. \*) Requires that the `DeviceMonitoring` module is deployed and running on the device. # Insights ### Insights The **Insights** section in Tricloud Nexus is your central hub for data exploration, analysis, and visualization. It brings together a suite of powerful tools that help you unlock actionable value from all the measurements, events, and KPIs collected across your industrial assets. Whether you want to perform quick diagnostics, investigate trends, build dashboards, or run custom queries, the Insights workspace provides everything you need to transform raw data into real business intelligence. *** ### Key Features **Time Series Explorer**\ Quickly analyze, visualize, and compare historical and real-time data from any tag or asset in your hierarchy. Drill down into trends, spot anomalies, and gain operational awareness with just a few clicks.

Time Series Explorer

**Dashboards**\ Build interactive dashboards to monitor KPIs, production metrics, equipment performance, and process health. Customize layouts, add charts and tiles, and securely share insights with your team.

Dasboards

**Queries:**\ Run advanced, ad-hoc queries directly against your time-series or historical data sources. Visualize query results, extract deeper insights, and power custom reporting or analytics use cases.

Query Editor

*** ### Typical Use Cases * Track production OEE, quality, and downtime at a glance * Monitor environmental conditions, alarms, or process deviations * Perform root cause analysis on equipment or process failures * Feed data to business intelligence or reporting systems * Collaborate and share insights with stakeholders across your organization #### Navigating the Insights Menu The Insights menu is organized into three main areas: * [**Time Series Explorer** ](/management-portal/insights/time-series-explorer)– View and analyze data from your devices and assets historically or in real-time. * [**Dashboards** ](/management-portal/insights/dashboards)– Create, edit, and share dashboards with flexible permissions and powerful visualization options. * [**Queries** ](/management-portal/insights/queries)– Build and run queries to answer specific business or operational questions, or prepare data for further analysis. > **Tip:** You can always access the Insights section from the main navigation panel on the left. Each sub-section includes its own help articles and troubleshooting guides for more advanced usage. *** **Start exploring your data in Insights to accelerate decision-making, optimize operations, and maximize the value of your IIoT investments.** # Time Series Explorer The Time Series page of the Management portal enables exploration of data, either historically or real-time, by visualizing measurements/events as time series. This guide will help you familiarize with the Time Series Explorer to gain insights from data. *** ## Introduction The Time Series Explorer is a tool designed to enable users to quickly analyze and gain insights from measurement data or events associated with specific tags. It allows users to compare multiple tags, view historical trends, and monitor real-time data streams without requiring any special programming skills. *** ## Key Features

Time Series Explorer

1. **Asset Hierarchy selection & Tag Navigation**: * Select an Asset Hierarchy to explore data from. * Navigate through your tags using either the hierarchical structure of assets or using list view, to find the tags you need. 2. **Tag Selection and Filters**: * Search and filter assets using the input box to locate specific tags quickly. * Hide undeployed nodes to focus only on active data sources. * Double click any Tag to add its associated measurements to the time series graphs. 3. **Historical and Real-Time Data Views**: * Toggle between **Historical** and **Realtime** views to analyze past data or monitor ongoing measurements. * The timeline slider lets you select custom date ranges for precise analysis of historical trends. 4. **Visualization Options**: * View line graphs that show data trends for selected tags eg. avg, min, max or standard deviation. * Easily compare multiple tags by adding them from the tag navigation view. * Adjust resolution for a more granular or aggregated view of data. 5. **Stream Playback**: * Enable the live data stream for real-time monitoring of tag measurements. * Pause or resume playback using the controls available next to each tag. *** ## Asset Hierarchy selection & Tag Navigation The Asset Hierarchy Selector in the top lets you select an Asset Hierarchy to explore. Only Asset Hierarchies, that have been deployed to a device can be selected.

Toolbar of Time Series Explorer

* The Asset Hierarchy selector also lets you filter between deployed hierarches using text when expanding it, if you have many Asset Hierarchies to choose from. * The Refresh button refreshes the Time Series Explorer available Asset Hierarchies and clears any Tag selection or data already loaded into the page. * The Live data stream icon in the toolbar indicates whether the Time Series Explorer is currently connected to an Edge device (Its only connected if a Real-time data stream is started). Once an Asset Hierarchy has been selected and loaded, all the Tags of the hierarchy will be shown either in in the Hierarchical view or List view. *** ### Hierarchical view The Hierarchical view shows the selected Asset Hierarchy using a hierarchical structure in its latest deployed version.

The Hierarchical view. The last Tag in the list is currently not deployed.

* The input text field in the top, lets you search the hierarchy for any node or tag that matches the input text. * The hide undeployed nodes switch, enables you to hide any Asset Node or Tag that is not currently deployed. By default all Nodes and Tags are shown, but their names are greyed out in the asset hierarchy tree, to indicate they are currently not deployed. {% hint style="info" %} Even though a Tag might not currently be deployed, historical measurements can still be loaded, if it has been deployed previously. However, it is not possible to start a Live-stream from the Tag, since it requires a device to stream the measurements. {% endhint %} *** ### List view The List view shows only the Tags that has been deployed from the selected Asset Hierarchy, leaving out the contextual information you would get from using the Hierarchical view. A list of Tags is shown as an alphabetically sorted list on the hierarchical name of the Tag.

The List view shows Tags sorted alphabetically

* The input text box in the Top, lets you filter the list of Tags to only show nodes containing the text entered into the text field. * The hide undeployed nodes switch, enables you to hide any Tag that is not currently deployed. By default all Nodes and Tags are shown, but their names are greyed out in the list, to indicate they are currently not deployed. *** ### Adding Tags to Time Series Regardless of whether you are navigating tags through the **Hierarchical** or **List** view, you can easily access a context menu by either right-clicking on a tag or clicking the icon ![](/files/avHBj6sERUJ808Yo9T7E) that appears when hovering your mouse over a Tag. This menu provides the following options: * **Add to timeseries:** Adds the selected Tag to the Tag list located at bottom of Historical - and Real-time Data View and loads measurements or events into the graphs. * **Remove from timeseries:** Removes the selected Tag from the Tag list, removing any graph that might be visualized for the Tag. * **View Asset Model:** Will navigate to the [Asset Designer](/management-portal/designer/assets) and select the owning Asset Hierarchy. * **View Device:** Will navigate to [Monitoring](/management-portal/operations/monitoring) and select the Device where the Tag is currently deployed. * **View Deployment:** Navigates to [Deployments](/management-portal/management/deployments) and selects the deployment that was responsible for this Tag to be available on a device. {% hint style="info" %} Instead of using the context-menu to add Tags to the graphs, you can simply double-click a Tag in either Hierarchical- or List view to load measurements from the Tag. {% endhint %} When tags are added to the Tag list at the bottom of the graphs, the Time Series Explorer automatically retrieves measurements for the selected tags. It then renders graphs based on the Tag type, whether it is Analog, Digital, or String, ensuring that the data is appropriately visualized for effective analysis.

The Tag list lets you manage Tags for visualization

The Tag list has the following columns: * **Tag Icon:** An icon that indicates whether the Tag type is Analog, String or Digital (As shown above). * **Graph Color:** Shows the chosen color for the visualization of the Tag in the graphs. The color can be changed at any time, by simply clicking the colored box. * **Name**: Tag name identifier. * **Stream**: The button lets you Play/Stop real-time data stream from the Tag. When Play is toggled, the Time Series Explorer will automatically navigate to the Real-time view. * **Action**: Removes the selected Tag from the Tag list, removing any graph that might be visualized for the Tag. * **Tag**: The ISA95 hierarchical name of the Tag. {% hint style="info" %} By default, the Time Series Explorer supports up to 2 simultaneous real-time data streams. This limit can be customized in the [Platform Settings](/management-portal/platform-settings), allowing users to increase or decrease the number of streams based on their environment. {% endhint %} # Historical Data View This page explains the Historical Data View. *** ### Visualize Your Data The Historical Data View provides a detailed visualization of Tag measurements over time, showcasing all data sent to the Asset Hierarchy's data store. It dynamically displays measurements for all Tags selected in the Tag selection table, located at the bottom of the screen. Each Tag is rendered appropriately based on its specific data type, ensuring accurate and intuitive representation.

Visualization of Analog, Digital- and String Tag

The Historical Data View automatically pre-aggregates measurements before visualization to prevent excessive data from being loaded due to the resolution of the time series. For example, in the screenshot above, a 1-day interval has been selected for visualization. As a result, all measurements within that timespan have been aggregated into 15-minute bins, ensuring efficient and clear representation. * **Analog Tags** are represented with an average line accompanied by a shaded area that illustrates the minimum and maximum values within each bin. * **Digital Tags** Digital Tags are displayed as bar graphs showing the percentage of time the Tag was On or Off in each bin. * **String Tags** No actual string values are represented, instead a graph showing the count of values in each bin is shown, as strings cannot be meaningfully aggregated. To get the actual values you can run a query. {% hint style="info" %} Measurements used for time series rendering are sent from the devices within the Asset Hierarchies either as real-time streams (hot path) or as batched data (cold path). As a result, historical data visualization may experience delays ranging from a minute to several hours, depending on the storage settings of the Tag. {% endhint %} *** ### Time Range Selection At the top of the Historical Data View, the time range selector allows you to define the specific timeframe for visualization. This selector also provides an overview of the distribution of measurements stored in the underlying data store for the selected Asset Hierarchy. In the example shown, no measurements are available within the currently selected time range; however, data is available prior to the selected period.

The time range selector shows measurements distribution of the data store for the selected Asset Hierarchy

Once a time range has been selected, and time series are rendered in the graph area, the user can use the mouse to select a more fine grained selection by holding down the left mouse button, and dragging a selection directly in the graph. When releasing the mouse button, a small menu appear that lets you zoom to your selection.

Dragging a time range selection using the mouse directly in the graph area

By default, the time range is displayed in the user's local time zone, as determined by the browser settings. However, this can be adjusted through the Timeframe dropdown menu, which becomes accessible by clicking on the displayed Timeframe dates.

The Timeframe dropdown menu, allows fine grained time range selection and selection of time zone

The time range selection area includes a Resolution slider that allows users to adjust the resolution of the visualized data. The time range selector automatically determines the most optimal resolution based on the selected timespan; a longer timespan results in a higher resolution, while a shorter timespan provides a more detailed view.

The resolution slider determines the timespan of the aggregated bins

*** ### Visualization Options When an analog Tag is selected for visualization, users can fine-tune which part of the time series is displayed. By default, the time series for any analog Tag shows the average value of each bin. However, using the dropdown menu next to the analog Tag, this can be adjusted to display the minimum (min), maximum (max), or standard deviation (stdev) instead.

Changing visualization of an analog Tag

You can use the icon that looks like an eye, to toggle whether to render the Tag. *** ## Real-time Data view By default, the Time Series Explorer opens in the Historical Data View. However, users can switch to the Real-time Data View by selecting the Realtime tab at the top of the graph area. Unlike the Historical Data View, the Real-time Data View streams measurements directly from the device where the Tag is deployed, resulting in a delay of only milliseconds for each datapoint. Since data is streamed in real time as it is generated, there is no time range selection or value aggregation in this view.

The Real-time Data View live streaming 3 tags from a device

{% hint style="info" %} You can use the Real-time Data View to check whether a given Tag has been properly configured and is receiving data on the device. {% endhint %} *** ### Stream playback To start a real-time stream from a Tag, simply click the Play button next to the Tag in the Tag list table at the bottom of the screen. If the Tag is currently receiving data, measurements should be rendering after a few seconds.

Real-time data streaming of 2 tags

{% hint style="info" %} Several factors can influence whether a Tag can be successfully streamed in real-time.: * Tag must be deployed and properly configured * If the Tag relies on a Data Collector, the Data Collector must also be correctly configured. * Additionally, the Tag's resolution should be set to seconds rather than milliseconds, as finer resolutions may cause the view to struggle with updates. {% endhint %} To stop streaming a Tag simple click the Stop button next to the Tag in the Tag list table. *** ## Example Use-cases The following section will describe 2 common use-cases that the Time Series Explorer can help users solve. ### **Monitoring Production Line Efficiency** **Scenario**: A factory manager wants to figure out, why a drop in production quality occurred on the 10th. of December. He suspects that environmental metrics might be causing the issues. So he wants to visualize the Temperature and Humidity of the line. **Steps**: 1. He selects the Asset Hierarchy for the production line and navigates to the proper node in the hierarchical view. 2. He adds the `Temperature` and `Humidity` tags to the Tag list using either the context menu or by double-clicking the tags. 3. He switches to the Historical Data View to see the temperature and humidity readings in the days leading up to the 10th. of December. 4. Compare the min, max, and average values of the `Temperature` tag and observe how fluctuations correlate with spikes or drops in `Humidity`. 5. He notices that there is a correlation between Temperature and Humidity. When the temperature rises the humidity drops and vice versa.

Visualizing data in graphs can make it easier to spot correlations between Temperature and Humidity

**Outcome**: The manager identifies that maintaining humidity and temperature within a specific range improves production quality and reduces downtime, enabling proactive adjustments. *** ### **Validating Sensor Configuration in Real-Time** **Scenario**: An engineer has recently deployed a new sensor to monitor vibration levels on a critical piece of machinery and needs to validate its configuration. **Steps**: 1. She navigates to the Asset Hierarchy where the sensor is deployed and locate the `Vibration` tag in the hierarchical view. 2. She adds the `Vibration` tag to the Tag list and switch to the Real-time Data View. 3. She starts the real-time data stream by clicking the Play button next to the tag in the Tag list. 4. She observes the live data stream to ensure the sensor is transmitting valid readings without delays or interruptions. 5. Use the timeline to compare the live stream data with historical records to verify that the sensor is configured for the correct resolution and frequency. **Outcome**: The engineer confirms that the sensor is properly configured and streaming accurate data, allowing it to be integrated into predictive maintenance workflows. *** ## Troubleshooting ### Asset Hierarchy not available for selection * **Cause**: The Asset Hierarchy has not yet been deployed to any device. Only Asset Hierarchies that has been deployed will be selectable for visualization in the Time Series Explorer. * **Solution**: 1. Check that the Asset Hierarchy has been deployed in the [Device Configuration](/management-portal/management/device-configuration). 2. Deploy the Asset Hierarchy to a Device. *** ### **No data displayed in Historical Data View** * **Cause**: The selected tags might not have historical data available for the chosen time range. * **Solution**: 1. Check the time range selection in the timeline at the top of the Historical Data View to see if the selected asset hierarchy contains any data in the data store. 2. Check the time range selection in the timeline at the top of the Historical Data View and adjust it to a period where data is expected. 3. Ensure the tags are deployed and have been collecting data. 4. Confirm the tags have been properly configured to send data to the Asset Hierarchy’s data store. *** ### **Real-time data not streaming** * **Cause**: The tag may not be correctly deployed or configured for live streaming. * **Solution**: 1. Verify that the tag is currently deployed to a device in the Asset Hierarchy. 2. Ensure the data collector responsible for the tag is active and correctly configured. 3. Check that the tag’s resolution is set to seconds rather than milliseconds, as finer resolutions may cause performance issues. 4. Confirm that the Edge device is connected, indicated by the Live Data Stream icon in the toolbar. *** ### **Slow or delayed data rendering** * **Cause**: Excessive data or high-resolution tags may cause rendering delays in the graphs. * **Solution**: 1. Use the resolution slider in the Historical Data View to aggregate data into larger bins for improved performance. 2. Reduce the number of tags added to the time series graphs simultaneously. 3. Check network latency if using remote connections to access the Asset Hierarchy. *** ### **Tag appears greyed out in Hierarchical- or List View** * **Cause**: The tag is not currently deployed to a device. * **Solution**: 1. Use the “Hide undeployed nodes” toggle to simplify the view and focus on active tags. 2. If the tag has historical data, it can still be added to the Historical Data View for analysis. *** ### **Measurements appear incorrect or inconsistent** * **Cause**: Tag configuration errors or device calibration issues may lead to inaccurate data. * **Solution**: 1. Validate the tag’s configuration in the[ Asset Designer](/management-portal/designer/assets/asset-hierarchies) to ensure proper setup. 2. Check the connected device for any calibration or sensor issues. 3. Compare measurements with known benchmarks or reference values. *** ### **Cannot add more Real-time streams** * **Cause**: The maximum number of simultaneous real-time streams has been reached. * **Solution**: 1. Stop one of the existing streams by clicking the Stop button in the Tag list table. Then start the Tag you want to stream- 2. Increase the limit of real-time streams in [Platform Settings](/management-portal/platform-settings), if your environment allows for additional capacity (This requires administrator privileges). *** ### **Time range selection not showing data** * **Cause**: The selected time range may not align with the stored measurements in the data store. * **Solution**: 1. Check the time range distribution graph in the timeline to ensure data exists within the selected range. 2. Use the Timeframe dropdown to refine the time selection. 3. Expand the time range to ensure coverage of any sparse data periods. *** ### **Graphs not updating after adding tags** * **Cause**: The page may not have refreshed the data correctly. * **Solution**: 1. Use the Refresh button in the toolbar to reload the Asset Hierarchy and tag data or refresh the entire webpage using F5. 2. Confirm that the tags have been properly added to the Tag list and are active for visualization. 1. **No Data Displayed**: * Ensure the selected tags are active and have associated data. * Check the timeline range for availability of historical data. # Real-time Data View This Page explains the Real-time Data View. *** ### Live Stream Data from your equipment By default, the Time Series Explorer opens in the Historical Data View. However, users can switch to the Real-time Data View by selecting the Realtime tab at the top of the graph area. Unlike the Historical Data View, the Real-time Data View streams measurements directly from the device where the Tag is deployed, resulting in a delay of only milliseconds for each datapoint. Since data is streamed in real time as it is generated, there is no time range selection or value aggregation in this view.

The Real-time Data View live streaming 3 tags from a device

{% hint style="info" %} You can use the Real-time Data View to check whether a given Tag has been properly configured and is receiving data on the device. {% endhint %} *** ### Stream playback To start a real-time stream from a Tag, simply click the Play button next to the Tag in the Tag list table at the bottom of the screen. If the Tag is currently receiving data, measurements should be rendering after a few seconds.

Real-time data streaming of 2 tags

To stop streaming a Tag simple click the Stop button next to the Tag in the Tag list table. {% hint style="info" %} Several factors can influence whether a Tag can be successfully streamed in real-time.: * Tag must be deployed and properly configured * If the Tag relies on a Data Collector, the Data Collector must also be correctly configured. * Additionally, the Tag's resolution should be set to seconds rather than milliseconds, as finer resolutions may cause the view to struggle with updates. * Please [Troubleshooting](/management-portal/insights/time-series-explorer/troubleshooting) section for further details. {% endhint %} # Use cases of Time Series Explorer This page highlights key use cases where the Time Series Explorer can provide valuable solutions. *** ## Example Use cases The following section will describe 2 common use cases where the Time Series Explorer can provide valuable solutions. ### **Monitoring Production Line Efficiency** **Scenario**: A factory manager wants to figure out, why a drop in production quality occurred on the 10th. of December. He suspects that environmental metrics might be causing the issues. So he wants to visualize the Temperature and Humidity of the line. **Steps**: 1. He selects the Asset Hierarchy for the production line and navigates to the proper node in the hierarchical view. 2. He adds the `Temperature` and `Humidity` tags to the Tag list using either the context menu or by double-clicking the tags. 3. He switches to the Historical Data View to see the temperature and humidity readings in the days leading up to the 10th. of December. 4. Compare the min, max, and average values of the `Temperature` tag and observe how fluctuations correlate with spikes or drops in `Humidity`. 5. He notices that there is a correlation between Temperature and Humidity. When the temperature rises the humidity drops and vice versa.

Visualizing data in graphs can make it easier to spot correlations between Temperature and Humidity

**Outcome**: The manager identifies that maintaining humidity and temperature within a specific range improves production quality and reduces downtime, enabling proactive adjustments. *** ### **Validating Sensor Configuration in Real-Time** **Scenario**: An engineer has recently deployed a new sensor to monitor vibration levels on a critical piece of machinery and needs to validate its configuration. **Steps**: 1. She navigates to the Asset Hierarchy where the sensor is deployed and locate the `Vibration` tag in the hierarchical view. 2. She adds the `Vibration` tag to the Tag list and switch to the Real-time Data View. 3. She starts the real-time data stream by clicking the Play button next to the tag in the Tag list. 4. She observes the live data stream to ensure the sensor is transmitting valid readings without delays or interruptions. 5. Use the timeline to compare the live stream data with historical records to verify that the sensor is configured for the correct resolution and frequency. **Outcome**: The engineer confirms that the sensor is properly configured and streaming accurate data, allowing it to be integrated into predictive maintenance workflows. # Troubleshooting This page can help you troubleshoot some of the most common issues expereinced when using the Time Series Explorer. *** ## Troubleshooting ### Asset Hierarchy not available for selection * **Cause**: The Asset Hierarchy has not yet been deployed to any device. Only Asset Hierarchies that has been deployed will be selectable for visualization in the Time Series Explorer. * **Solution**: 1. Check that the Asset Hierarchy has been deployed in the [Device Configuration](/management-portal/management/device-configuration). 2. Deploy the Asset Hierarchy to a Device. *** ### **No data displayed in Historical Data View** * **Cause**: The selected tags might not have historical data available for the chosen time range. * **Solution**: 1. Check the time range selection in the timeline at the top of the Historical Data View to see if the selected asset hierarchy contains any data in the data store. 2. Check the time range selection in the timeline at the top of the Historical Data View and adjust it to a period where data is expected. 3. Ensure the tags are deployed and have been collecting data. 4. Confirm the tags have been properly configured to send data to the Asset Hierarchy’s data store. *** ### **Real-time data not streaming** * **Cause**: The tag may not be correctly deployed or configured for live streaming. * **Solution**: 1. Verify that the tag is currently deployed to a device in the Asset Hierarchy. 2. Ensure the data collector responsible for the tag is active and correctly configured. 3. Check that the tag’s resolution is set to seconds rather than milliseconds, as finer resolutions may cause performance issues. 4. Confirm that the Edge device is connected, indicated by the Live Data Stream icon in the toolbar. *** ### **Slow or delayed data rendering** * **Cause**: Excessive data or high-resolution tags may cause rendering delays in the graphs. * **Solution**: 1. Use the resolution slider in the Historical Data View to aggregate data into larger bins for improved performance. 2. Reduce the number of tags added to the time series graphs simultaneously. 3. Check network latency if using remote connections to access the Asset Hierarchy. *** ### **Tag appears greyed out in Hierarchical- or List View** * **Cause**: The tag is not currently deployed to a device. * **Solution**: 1. Use the “Hide undeployed nodes” toggle to simplify the view and focus on active tags. 2. If the tag has historical data, it can still be added to the Historical Data View for analysis. *** ### **Measurements appear incorrect or inconsistent** * **Cause**: Tag configuration errors or device calibration issues may lead to inaccurate data. * **Solution**: 1. Validate the tag’s configuration in the[ Asset Designer](/management-portal/designer/assets/asset-hierarchies) to ensure proper setup. 2. Check the connected device for any calibration or sensor issues. 3. Compare measurements with known benchmarks or reference values. *** ### **Cannot add more Real-time streams** * **Cause**: The maximum number of simultaneous real-time streams has been reached. * **Solution**: 1. Stop one of the existing streams by clicking the Stop button in the Tag list table. Then start the Tag you want to stream- 2. Increase the limit of real-time streams in [Platform Settings](/management-portal/platform-settings), if your environment allows for additional capacity (This requires administrator privileges). *** ### **Time range selection not showing data** * **Cause**: The selected time range may not align with the stored measurements in the data store. * **Solution**: 1. Check the time range distribution graph in the timeline to ensure data exists within the selected range. 2. Use the Timeframe dropdown to refine the time selection. 3. Expand the time range to ensure coverage of any sparse data periods. *** ### **Graphs not updating after adding tags** * **Cause**: The page may not have refreshed the data correctly. * **Solution**: 1. Use the Refresh button in the toolbar to reload the Asset Hierarchy and tag data or refresh the entire webpage using F5. 2. Confirm that the tags have been properly added to the Tag list and are active for visualization. 1. **No Data Displayed**: * Ensure the selected tags are active and have associated data. * Check the timeline range for availability of historical data. # Dashboards The Dashboards page of the Management portal allows you to build your own dashboards enabling improved insights into data. This page will help explain some fundamentals of using dashboards to gain insights into data. *** ## Introduction A dashboard is a collection of tiles, optionally organized in pages, where each tile has an underlying query and a visual representation. Using the Dashboards UI can write KQL queries to extract data and modify visual formatting as needed. In addition to ease of data exploration, this fully integrated Azure Data Explorer dashboard experience provides improved query and visualization performance. ### Dashboard Benefits * **Data-Driven Decision Making:** Dashboards consolidate key metrics in one place, making it easier to identify trends and take actionable steps. * **Real-Time Insights:** Dynamic updates ensure users always have the latest data at their fingertips. * **Enhanced Collaboration:** Share dashboards with team members for improved transparency and coordination. {% hint style="info" %} The built-in dashboards are based on Azure Data Explorer dashboards technology. Therefore a complete guide into using the dashboards can also be found on Microsoft's official [Azure Data Explorer Dashboards documentation page](https://learn.microsoft.com/en-us/azure/data-explorer/azure-data-explorer-dashboards). {% endhint %} *** ## Key features

Example of an OEE dashboard

1. **Build and share dashboards:** * Dashboards can built and shared with other users. * Define access rights to dashboards. 2. **Integration with Data Stores:** * The dashboards leverage Azure Data Explorer Data Stores, ensuring high-performance querying and seamless integration with KQL (Kusto Query Language). * Users can benefit from built-in ADX features such as data transformations and aggregations. 3. **Customizable Layouts:** * Dashboards can be organized into pages and customized layouts, allowing flexibility in presenting different datasets. 4. **Interactive Visualizations:** * Each tile on a dashboard is equipped with interactive visualizations, such as charts, tables, and graphs. * Users can drill down into specific data points for detailed analysis. 5. **User-Friendly Interface:** * The UI is intuitive and designed for both technical and non-technical users. * Features like drag-and-drop tile placement and a robust query editor simplify dashboard creation. # Navigating Dashboards *** ## Navigating the Dashboards Page You can navigate to the Dashboard page using the main menu and clicking Insights | Dashboards.

The Dashboards page is located in the Insights menu

1. **Dashboards Overview:** * The first page shown when entering Dashboards is the Dashboards overview page. * This page provides an overview of all available dashboards, with filtering options like "Recent," "All," and "Favorites" to quickly locate dashboards. * Key columns include: * **Name:** The dashboard title. Clicking on the name opens the dashboard. * **Last Accessed:** When the dashboard was last used. * **Created Date:** The date the dashboard was created. * **Created By:** The author of the dashboard.

The dashboard overview page

1. **Dashboards Actions:** * Clicking the 3 dots ![](/files/VTmstxhGwtMs4IujlNZP) in the last column of the dashboards table, brings up a context menu with the following options: * **Copy link** Copies an URL Link to the dashboard, which can be emailed to other users, and opens up the Dashboard outside Nexus management portal. By default the link will point to the following address: \ If you want the link to point to the Dashboard inside Nexus Management portal, you just need to replace the first part of the Url, eg: https\://\/dashboards/\ *

Manage Dashboard Permissions Dialog

* **Duplicate dashboard** Duplicates the Dashboard with a new name, effectively taking a copy. * **Replace dashboard with file** Replaces the dashboard with a dashboard from a file that has been previously exported. * **Download dashboard file** Exports the dashboard to a Json based file. {% hint style="info" %} **Note**: Before any user can access a dashboard that you shared, the User must first click/navigate to an URL that points to the dashboard. Navigating to the dashboard adds the shared dashboard to their dashboards overview page, and allows them to open the dashboard, if they have been granted the permission. {% endhint %} # Create a Dashboard *** ## Create a new Dashboard

The Dashboard overview page

In order to create a new dashboard, you can use the drop-down button in the upper left corner of the Dashboard page. You can create a new Dashboard from scratch by providing a name, create it from a previously exported dashboard file. Alternatively you can create a dashboard from a set of sample dashboards to help you get started.

Create new dashboard options

You must provide a name for your Dashboard, that havent allready been used.
Save the Empty dashboard, by clicking **Save** in the upper right hand corner.
When the Empty Dashboard has been created, you can now do the following actions: * [Assign Permisions ](#manage-dashboard-permissions)to dashboard * [Add Data Sources](/management-portal/insights/dashboards/create-a-dashboard/add-data-sources) to establish connections to data * [Add Tiles](/management-portal/insights/dashboards/create-a-dashboard/add-tiles) to visualize your data * [Use Parameters](/management-portal/insights/dashboards/create-a-dashboard/use-parameters) to filter data to visualize # Manage Dashboard Permissions *** ### Manage Dashboard Permissions To manage the permisions of a dashboard, you must first navigate to the dashboards page, and find the dashboard you want to manage in one of the tabs *Recent, All* or *Favorites.*

Click the action menu (3 dots) then click manage permisisons

### Set Permissions The Manage Permissions dialog lets you define who can View or Edit the dashboard. You can search for Users or AD groups, then select a permission (can Edit or can View) and click the Add button
{% hint style="info" %} **Note**: Before any user can access a dashboard that you shared, the User must first click/navigate to an URL that points to the dashboard. Navigating to the dashboard adds the shared dashboard to their dashboards overview page, and allows them to open the dashboard, if they have been granted the permission. {% endhint %} ### Send Dashbord Link to User To share a dadhboard with another user, you must copy a link to the Dashboard and send it to the User.

Click the action menu (3 dots) then click Copy link

The **Copy Link** action copies a direct link to the dashboard to your clipboard. You can easily share this link with others—for example, by emailing it to other users. Clicking the link will open the dashboard outside the Nexus Management Portal by default, using the following format:\ `https://dataexplorer.azure.com/dashboards/` If you prefer the link to open within the Nexus Management Portal instead, simply replace the first part of the URL with the path to your portal. For example:\ `https:///dashboards/` {% hint style="info" %} **Note**: Before any user can access a dashboard that you shared, the User must first click/navigate to an URL that points to the dashboard. Navigating to the dashboard adds the shared dashboard to their dashboards overview page, and allows them to open the dashboard, if they have been granted the permission. {% endhint %} # Add Data Sources *** ### Add a Data Source A Dashboard can use several different data sources to display visuals from. In the following example we will add the default data store of Tricloud Nexus as data source. You will need to copy the Host Address of the Data store (Data Explorer Cluster URL) from Platform Settings. 1. Navigate to Platform Settings, select the Data Stores tab, then copy the Host Address of the Data Store you need for your dashboard visualization.

Copy the Host Address of the ADX Cluster from Platform Settings

2. Go back to your Dashboard
{% hint style="info" %} If you have multiple Data stores in use by different Asset Hierarchies, you can simple import them as Data sources. {% endhint %} # Add Tiles *** ### Add a Tile Dashboard tiles use [Kusto Query Language (KQL)](/management-portal/insights/queries#learning-kusto-query-language-kql) snippets to retrieve data and render visuals. Each tile/query can support a single visual.

Adding a Tile to a blank Dashboard

When you add a Tile, you must select a data source that will be used to retrieve data for the Tile (If no data sources is available please see [Add Data Source](/management-portal/insights/dashboards/create-a-dashboard/add-data-sources)) In the **Query** pane of the Tile: 1. Select the data source from the drop-down menu. 2. Type the query, and the select **Run**. For more information about generating queries that use parameters, see [Use Parameters](/management-portal/insights/dashboards/create-a-dashboard/use-parameters). 3. Select the **Visual Tab**

Select Data source, Insert a Query and choose a Visual type for the Tile

4. In the visual tab, select **Visual type** to choose the type of visual (Line chart) 5. In the **Data** section, select the property to use for Y columns (Y-Axis), in this case we use the Value of the selected Measurements. Set the X-Axis to use the StartTimestamp of the Measurements. Finally you can specify how your Series should be named, in this case we use the HierarchicalName of the Measurements. 6. Select **Apply changes**
7. You can resize the Tile directly on the dashboard surface, then click **Save.** In order to Add 8. In order to edit an existing Tile, you must be sure that the Dashboard is put into **Editing mode**

Putting a dashboard into Editing mode requires the right permissions

{% hint style="info" %} A Tile will only load a maximum of about 50.000 Data points. If your time range selection yields above this threshold, you can use Aggregation queries to limit the amount of data points being visualized, eg. by showing calculated average values in time buckets. Please see [Summarize Operator](/management-portal/insights/queries#summarize-operator) or [Make-series Operator ](/management-portal/insights/queries#make-series-operator)for details. {% endhint %} For more details on customizing visuals, please see Microsoft Dooumentation [Azure Data Explorer Customize dashboard visuals](https://learn.microsoft.com/en-us/azure/data-explorer/dashboard-customize-visuals). *** # Use Parameters *** ### Default Parameter By default a newly created dashboard will contain the **Time Range** parameter, which lets the user choose a default timerange for the data that appears in the dashboard. By clicking on the Parameters button in the top menu, you are able to edit the Time range parameter by clicking the pen icon.

Click Parameters then click edit on the Time range parameter

This should open up the Edit Parameter dialog, en lets you view the details of the Time range parameter.

The Edit Parameter dialog

* The ***label*** is the name of the parameter that is used in the dashboard * The ***Parameter type*** can be set to either Single selection, Mutliple select, Free text, Time range and Data source. * The ***starttime*** and ***endtime varable names***, are the variable name(s) that can be used in dashboard tiles/queries to use the selected value of the parameter. * The ***Show on pages*** lets you set which pages of the dashboard should include the parameter. * The ***defult value*** is the value that the parameter should have when first initialized. ### Create a custom Parameter Parameters can be used in Dashboards to filter on data that is being visualized. Using parameters also significantly improve dashboard rendering performance, because values are filtered as early as possible in the query. Filtering is enabled when the parameter is included in the query associated with a tile. For more detailed information about how to set up and use different kinds of parameters see [Use parameters in dashboards](https://learn.microsoft.com/en-us/azure/data-explorer/dashboard-parameters). 1. Click the **Parameters** button in the top of the dashboard. 2. Click the **Add** button.

Add a new Parameter to a dashboard

4. You must specify a Name for the **Label** (Will be shown in Dashboard selection) 5. Give it an optional description and set a **Variable Name** that can be used in your queries as a filter 6. Set it to be shown on the currently selected **Page** 7. Select **Query** and click **Edit Query** to specify the Query Then add the following Query into the dialog: ```kusto Measurements | where StartTimestamp between (_startTime .. _endTime) | distinct HierarchicalName | order by HierarchicalName asc ```

Adding a Query to select Parameters.

8. In the **Add Query Dialog** you can specify your **Query**. 9. In the example above, we are using the Dashboard 's **Time range** filter to select the HierarchicalName of all available Measurements within the Period, then we order them in ascending alphabetically. 10. Click the **Add** button 11. Make sure to set the **Value column** in the Add Parameter Dialog is set to the HierarchicalName (The column name of the Query just specified)

The parameter should appear in the top of the dashboard

*** ### Use parameter to filter a Tile You can use the Parameter that the user has selcted to filter the data that is shown in Tiles. 1. Add a new Tile to the dashboard by clicking **Add/Add tile** 2. Add the following Query into the query textbox: ```kusto Measurements | where StartTimestamp between (_startTime .. _endTime) | where HierarchicalName has _hierarchicalName | order by StartTimestamp asc | limit 5000 ``` Notice the use of the parameters **\_*****startTime**, **\_*****endTime** and **\_hierarchicalName** in the query, to narrow down the search.

Using parameters to filter what data to load

The Query will load all Measurements from the Measurements table that has a StartTimestamp in the selecteed Time range and has the selected Tag name (HierarchicalName), it then orders the Measurements by StartTimestamp and then limits the query to only load 5000 data points. For more details on Parameters please see Microsoft Dooumentation and the [Azure Data Explorer Parameters](https://learn.microsoft.com/en-us/azure/data-explorer/dashboard-parameters). ### Visualize filtered data in a Tile 1. You can add visualization by clicking the **Add visual** button. Give the Tile a name. 2. Select the **Line chart** in the Visual type dropdown. 3. Make sure you select the **Value** of the measurements for the Y column (y-axis), and the **StartTimestamp** as the X columns (x-axis).

Visualize the filtered values for the selected Tag

If you have configured it correctly you should see a visualization similar to the above screenshot. {% hint style="info" %} The Visualization Type (Line chart) is only suitable for Measurements of Type **Analog** or **Digital**, since the Value type is a Real. For **String** measurements you can use a Table to visualize the data. {% endhint %} Having configured the Visual you can click the **Apply changes** then click **Save** to save the changes of the dashboard.

Dashboard using parameters

On the dashboard page - try and select different Time range and different Tag names, and watch how the Tile automatically fetches the filtered data and visualizes it. For more details on customizing visuals, please see Microsoft Dooumentation [Azure Data Explorer Customize dashboard visuals](https://learn.microsoft.com/en-us/azure/data-explorer/dashboard-customize-visuals). # Queries The Tricloud Nexus Query Editor is a powerful tool designed to help users query, analyze, and visualize data effortlessly. This guide will help you get started with using the Query Editor of Tricloud Nexus to analyze and gain insights from data efficiently. *** ## Introduction The Tricloud Nexus Query Editor is a powerful tool designed to help users query and analyze data effortlessly. Built on the Azure Data Explorer Query UI, it uses KQL (Kusto Query Language) for efficient data access and exploration. ### Learning Kusto Query Language (KQL) Here are some links to help you get started with the learning the KQL language. * Kusto Query documentation: * Quick Reference Guide: * Kusto Cheat Sheet; *** ### Accessing the Query Editor 1. **Login to Tricloud Nexus**: * Navigate to the Tricloud Nexus platform using your browser. * Enter your credentials and click **Login**. 2. **Open the Query Editor**: * Click on the **Query Editor** tab located in the navigation menu.

Query Editor

3. **Select the Database:** * In the Query Editor, your workspace is pre-configured to access the Azure Data Explorer database. * Ensure you have the necessary permissions to query the database. * Select the database as seen in the example screenshot above, and take notice that the database is selected above the query editor using the convention *cluster/databasename.* * In the example above the selection is: tciotadxcluster.westeurope/TimeSeriesSandbox02 which may differ depending on your installation. *** For more details see the following sections: * [Database Tables](/management-portal/insights/queries/database-tables) Definition of Tables in the database * [Creating a Query](/management-portal/insights/queries/creating-a-query) How to create your first query * [Basic Queries](/management-portal/insights/queries/creating-a-query/basic-queries) Basic operators * [Intermediate Queries](/management-portal/insights/queries/creating-a-query/intermediate-queries) Join, Summarize and make-series operators * [Advanced Queries](/management-portal/insights/queries/creating-a-query/advanced-queries) Trendline and Forecasting For more details on KQL, please see [Kusto Query Language](https://learn.microsoft.com/en-us/kusto/query/syntax-conventions?view=azure-data-explorer\&preserve-view=true) in Microsoft's documentation. # Database Tables ## Database Tables The Azure Data Explorer contains at least one database per environment. Each database contains a predefined schema of Tables. The Tables of the database are crucial for exploring and analyzing your data. This section provides an overview of the most commonly used Tables to help you get started. You can view the database structure by expanding the nodes in the **Database Explorer**. Among the available tables, the most relevant ones include:

The most relevant Tables for gaining Insights can be found in the Database Explorer

* **AssetHierarchy**: This Table contains information from Asset Hierarchies, that has been deployed to a Device. The Table details the organizational structure of deployed assets, featuring the latest version of each node— whether it is an Area or an Asset within any Asset Hierarchy. * **AssetHierarchyMetadata**: This Table contains metadata information from Asset Hierarchies, that has been deployed to a device. The Table provides metadata for all Area/Assets and Tags that has been configured for Asset hierarchies. * **Measurements**: Stores time-series measurements and events associated with your assets. The Table contains the actual metrics that has been collected from your devices. {% hint style="info" %} All timestamps in any Timestamp column is always represented in the Date format ISO8601 as UTC unless otherwise specified {% endhint %} *** ### AssetHierarchy Table This Table contains information from Asset Hierarchies, that has been deployed to a Device. The Table details the organizational structure of deployed assets, featuring the latest version of each node— whether it is an Area or an Asset within any Asset Hierarchy. Running this query, lets you get a list of latest available AssetHierarchies in the Database. ```kusto AssetHierarchy | distinct HierarchyName, HierarchyId, HierarchyVersion | order by HierarchyName asc ``` Beneath is an example result of running the query

Example of Query output showing current Hierarchies in the Database

Now that we can see all available Asset Hierarchies in the Table, we can now refine our search, to only show all Nodes from a specific Asset Hierarchy. Running the following query, will show the Asset Hierarchy nodes for the Asset Hierarchy called "*Odense Factory*". The Query only includes some of the available columns using the *project* operator. ```kusto AssetHierarchy | where HierarchyName == "Odense Factory" | project HierarchicalName, Type, Description, IsDeployed, DeploymentTimestamp, DeviceId | order by HierarchicalName asc ``` Here is an example result of running the query

Showing all Asset Hierarchy Nodes from the Odense Factory Hierarchy

Notice that by ordering the query result by HierarchicalName displays the result exactly as it was Modelled in Tricloud Nexus in that version. Also notice that you can see whether a Node has been deployed, when it was deployed and the device that was targeted for the deployment.

The Modelled Asset Hierarchy structure

*** ### AssetHierarchyMetadata Table This Table contains metadata information from Asset Hierarchies, that has been deployed to a device. The Table provides metadata for all Area/Assets and Tags that has been configured for Asset hierarchies. All metadata for an Area/Asset or Tag that has been deployed to a device, can found by running the query beneath. The query displays all metadata Key/Value objects for all available Asset Hierarchies. It removes some less important columns from the result (Id, IngestionTime, DataType). It then orders the result by the Type of metadata. ```kusto AssetHierarchyMetadata | project-away Id, IngestionTime, DataType | order by Type asc ``` Here is an example result of running the query

Available Asset Hierarchy Metadata

Notice that the first 2 rows are metadata about an Area that seemingly sets a GPS coordinate for the Area. The rest of the rows are metadata about a Tag such as uom (Unit Of Measure), description, ranges etc. You can combine an entire AssetHierarchy with the available metadata for all Area/Assets or Tags into a single query by joining the *AssetHierarchy* and *AssetHierarchyMetadata* Tables. The query combines all metadata available for a specific node into a json document (Key/Value) and stores this in the Metadata column. ```kusto AssetHierarchy | join kind=leftouter AssetHierarchyMetadata on Id | where HierarchyName == "Dallas Factory" | project Id, Name, HierarchicalName, MetadataKey = Key, MetadataValue = Value, DeploymentTimestamp | summarize Metadata = make_bag(pack(MetadataKey, MetadataValue)) by HierarchicalName | order by HierarchicalName asc ``` Result of running Query

Showing the Asset Hierarchy Structure along with all available Metadata for each Area/Asset or Tag

*** ### Measurement Table The Measurement Table stores time-series measurements and events associated with your assets. The Table contains the actual metrics that has been collected from the devices. The following Query, will find all available metrics/measurements that has a StartTimestamp between 17. the dec to 20. the dec. (UTC) for the Tag with the HierarchicalName *OD.Printing.Line.Temperature,* then order the result by StartTimestamp descending: ```kusto Measurements | where StartTimestamp between (datetime('2024-12-17T00:00:00') .. datetime('2024-12-20T00:00:00')) | where HierarchicalName contains "OD.Printing.Line.Temperature" | order by StartTimestamp desc ``` Result of running the Query

Measurement Query result

The result shows the structure of the Measurement Table, the Table has the following Columns: * **Id -** The Id of the Tag that governs measurements * **HierarcicalName -** ISA95 name for the Tag that governs the measurements * **TagName -** Shorthanded name of the Measurements * **TimeGenerated -** The UTC time the Measurement was generated at the Data Collector * **StartTimestamp -** The UTC start time of the Measurement * **EndTimestamp -** The UTC end time of the Measurement. Many measurements does not have an endtime specifed, denoting that the measurement does not have timespan. * **Type -** Measurement type. Can be either Analog, Digital or String. The Type depends on Tag type that was configured in the Asset Hierarchy. * **Value -** The value of the measurement as a real data type. This will likely only be set for measurements of type Analog or Digital. * **ValueDigital -** The value of the measurement as a boolean data type. This will likely only be set for measurements of type Digital and Analog. The database will automatically try and convert the value of the measurement to a boolean, by converting 1 to true and 0 to false. * **ValueString -** The value of the measurement as a string data type. This will likely only be set for measurements of type String. This is a very flexible data type and can be used for metrics that carries a complex data type such as Json. * **Quality -** The quality of the measurement. The quality of each measurement is set by the data collector on the device, that is used to collect the measurement from the destination data source. If a given measurement has a quality other than the value *good,* it is not recommended to use the measurements for training an AI model. {% hint style="info" %} The Measurement Table is indexed on the StartTimestamp column, which significantly improves Query performance for queries that starts by filtering data on this column. Example: `Measurements` `| where StartTimestamp > ago(2d)` {% endhint %} *** # Creating a Query *** ### Creating your first Query If you are in doubt were to find the Query editor or how to select a Database, please see [Queries](/management-portal/insights/queries). 1. **Familiarize yourself with KQL**: * The Query Editor uses KQL (Kusto Query Language) to query data. If you're new to KQL, refer to the [Queries](/management-portal/insights/queries#learning-kusto-query-language-kql)

Select a database in the connection tree to the left and write queries

2. **Build Your Query**: * Use the query editor interface to type your KQL commands. * This Query will show the name all Asset Hierarchies that has been deployed to a device, and sort them alphabetically by the name of the Asset Hierarchy: ```kusto AssetHierarchy | distinct HierarchyName | order by HierarchyName asc ``` 3. **Preview your Query**: * Click **Run** to execute the query and preview the results in the **Results** panel.

Running your first Query

*** ### Build another Query The query below tries to select 100 random measurements from the Database from the last 10 days. ```kusto Measurements | where StartTimestamp > ago(10d) | take 100 ``` This query will only return data, if a deployment to an Edge device has been done, and the Edge device has collected data from one or more data connections within the last 10 days.

Query returns some Measurments

*** ### Query specific Tag measurements From the query you ran before, try and copy the **HierarchicalName** from one of the Measurements in the Table, and then insert the name in the query below, where it says \. ```kusto Measurements | where StartTimestamp between (ago(10d) .. now()) | where HierarchicalName has "" | order by StartTimestamp asc | limit 5000 ``` The Query selects datapoints from the last 10 days from the chosen Tag (HierarchicalName). It orders the Measurements by its StartTimestamp in ascending order, then takes the first 5000 data points.
For more Queries please see: * [Basic Queries](/management-portal/insights/queries/creating-a-query/basic-queries) Basic operators * [Intermediate Queries](/management-portal/insights/queries/creating-a-query/intermediate-queries) Join, Summarize and make-series operators * [Advanced Queries](/management-portal/insights/queries/creating-a-query/advanced-queries) Trendline and Forecasting For more details on KQL, please see [Kusto Query Language](https://learn.microsoft.com/en-us/kusto/query/syntax-conventions?view=azure-data-explorer\&preserve-view=true) in Microsoft's documentation. # Basic Queries *** ## Basic Queries In this section, we'll cover some of the basic operators used in KQL queries, to help you begin exploring data in Tricloud Nexus. *** ### Where, order by, take operators Here's a query example showing how to filter measurements using the *Where* operator on both timespan and HierarchicalName. The *Order by* operator sorts these measurements in ascending order based on StartTimestamp. The *take* operator limits the output to the first 1000 rows (alternatively, you can use the *limit* operator). ```kusto Measurements | where StartTimestamp > ago(1d) | where HierarchicalName has "DA.IM.CoolingStorage.Temp" | order by StartTimestamp asc | take 1000 ``` Here is the result of running the query:

Where operator filters on time and name of measurment

The query above filters data on time using the *ago(1d)* expression. The following examples are alternatives ways of filtering by time: ```kusto | where StartTimestamp > ago(1h) // Include measurements less than an hour old | where StartTimestamp > ago(1m) // Include measurements less than a minute old | where StartTimestamp > datetime('') // Include measurements less than an hour old | where StartTimestamp > datetime('2025-01-16T12:00:00.000000Z') // Include measurements that is older than January 16. th 2025 12:00 UTC ``` *** ### Project, project-away operators This query example shows you how to query Measurements, then using the *project* operator to only include the columns HierarchicalName, TagName, StartTimestamp, Value in the result. ```kusto Measurements | where StartTimestamp > ago(1d) | where HierarchicalName has "DA.IM.CoolingStorage.Temp" | order by StartTimestamp asc | project HierarchicalName, TagName, StartTimestamp, Value | limit 1000 ``` Here is the result of running the query:

project operator sets the columns to include in the result

The *project-away operator* can be used, to exclude columns from the result, instead of using the *project* operator to specifically include the columns. ```kusto Measurements | where StartTimestamp > ago(1d) | where HierarchicalName has "DA.IM.CoolingStorage.Temp" | order by StartTimestamp asc | project-away Id, TimeGenerated, EndTimestamp, Type, ValueDigital, ValueString | limit 1000 ``` Here is the result of running the query:

project-away operator removes columns from the result

*** ### Extend operator The *extend* operator is used below, to generate new columns in the result, and calculate row values for the extended columns. ```kusto Measurements | where StartTimestamp > ago(1d) | where HierarchicalName has "DA.IM.CoolingStorage.Temp" | project StartTimestamp, HierarchicalName, Value | extend AdxRowInsertTime = ingestion_time() | extend DurationDifference = AdxRowInsertTime - StartTimestamp | extend FormattedDuration = format_timespan(DurationDifference, 'ddd.h:mm:ss [fffffff]') | take 1000 ``` The query above starts by finding measurements less than a day old from the CoolingStorage.Temp sensor. It then projects only the columns StartTimestamp, HierarchicalName and Value columns. It extends the result with 3 new columns. * **AdxRowInsertTime** will contain the exact UTC timestamp, that the row was created in the Database. * **DurationDifference** Substracts the StartTimestamp from the AdxRowInsertTime and then stores the timespan in the column. * **FormattedDuration** Formats the timespan datatype of the DurationDifference column and stores a strinng representation of the timespan. Here is the result of running the query:

Using the extend operator together with project can limit and extend the result set

*** # Intermediate Queries *** ## Intermediate Queries In this section, we'll cover some intermediate operators used in KQL queries, to help you begin exploring data in Tricloud Nexus. *** ### Let, join operators The query below retrieves data related to a specific asset hierarchy node ("DA.IM.P103.Line.OrderCompletion") from the AssetHierarchy and Measurements tables. It enriches the measurements data with metadata by joining it with the AssetHierarchyMetadata table and organizes the metadata into a structured bag format. The result of the first part of the query, is stored as a variable called metadata using the *let* operator. The second part then *joins* metadata with Measurements. The query filters measurements from the last 50 days, calculates the delivered items from dynamic properties, and selects relevant fields, limiting the output to 1,000 records sorted by the start timestamp. Using the *todynamic* operator lets you parse contents as json, and reference properties of the json, which is done in the query in this line toint(properties.deliverQuantity). ```kusto let metadata = AssetHierarchy | where HierarchicalName has "DA.IM.P103.Line.OrderCompletion" | join kind=leftouter AssetHierarchyMetadata on Id | where HierarchicalName has "DA.IM.P103.Line.OrderCompletion" | project Id, Name, HierarchicalName, MetadataKey = Key, MetadataValue = Value, Type | summarize Metadata = make_bag(pack(MetadataKey, MetadataValue)) by HierarchicalName, Type | order by HierarchicalName asc | project HierarchicalName, Type, Metadata; Measurements | where StartTimestamp > ago(50d) | where HierarchicalName has "DA.IM.P103.Line.OrderCompletion" | join kind=leftouter metadata on HierarchicalName | extend properties = todynamic(ValueString) | extend DeliveredItems = toint(properties.deliverQuantiy) | project StartTimestamp, HierarchicalName, DeliveredItems, Quality, Metadata | order by StartTimestamp asc | take 1000 ``` Here is the result of running the Query:

Measurement and Metadata is joined

*** ### Summarize operator The summarize operator can be used to produce a new table that aggregates certain values of the input table. The following Query filters the Measurements to include all Measurements from the Line (Regardless of Tag name), it then uses the *summarize* operator to group the measurements by HierarchicalName and perform a Count() on each group. ```kusto Measurements | where HierarchicalName startswith "DA.IM.P103.Line" | summarize Count = count() by HierarchicalName ``` Here is the result of running the Query:

Use summarize to count measurements per. Tag from a Line

The following Query produces a time chart showing the average number of items delivered every 1 day (grouped by HierarchicalName) between December 1, 2024, and December 20, 2024. It first defines parameters for the query using the let operator. It then selects all measruments for the Tag called ("DA.IM.P103.Line.OrderCompletion") and filters its measurements in the timespan from startTime to endTime. It converts the payload of the Tag (ValueString) into a dynamic, to parse the value of the json property deliverQuantity into an integer. It uses the *summarize* operator, to group all measurements into bins of 1 day using the *bin* operator to specify the binning column StartTime, and the timespan of each group using the totimespan(resolution). Finally it projects the columns StartTimestamp and AverageItemsDelivered and rounds the AverageItemsDelivered to 2 decimals. Using the *timechart* operator, will draw the result as a timechart. ```kusto let startTime = datetime("2024-12-01 00:00:00"); let endTime = datetime("2024-12-20 00:00:00"); let resolution = 1d; let tagName = "DA.IM.P103.Line.OrderCompletion"; Measurements | where StartTimestamp > startTime and StartTimestamp < endTime | where HierarchicalName has tagName | extend properties = todynamic(ValueString) | extend DeliveredItems = toint(properties.deliverQuantiy) | summarize AverageItemsDelivered = avg(DeliveredItems) by bin(StartTimestamp, totimespan(resolution)), HierarchicalName | project StartTimestamp, AverageItemsDelivered = round(AverageItemsDelivered, 2) | render timechart ``` Here is the result of running the Query:

The summarize operator can be used to aggregate bins of data using several operators

*** ### Make-series operator The following query uses the *make-series* to aggregate the average number of delivered items per. day and the minimum/maximum orders delivered in an order each day between October 1, 2024 to February 1, 2025. The main difference between using the *make-series* operator instead of the *summarize* operator in the previous example above, lies in how they handle time-based grouping and gaps in data. The summarize operator does not assume or enforce continuity in time intervals, but the make-series operator always generate a continuous time series, and fills any missing values with user defined default value. In the example below it defaults any missing data in a bin to 0 using the statement *default=0.* ```kusto let startTime = datetime("2024-10-01 00:00:00"); let endTime = datetime("2025-02-01 00:00:00"); let resolution = 1d; let tagName = "DA.IM.P103.Line.OrderCompletion"; Measurements | where StartTimestamp > startTime and StartTimestamp < endTime | where HierarchicalName has tagName | extend properties = todynamic(ValueString) | extend DeliveredItems = toint(properties.deliverQuantiy) | make-series avg(DeliveredItems), min(DeliveredItems), max(DeliveredItems) default=0 on StartTimestamp from startTime to endTime step totimespan(resolution) | project StartTimestamp, avg_DeliveredItems, min_DeliveredItems, max_DeliveredItems | render timechart ``` Here is the result of running the Query:\\

Make-series operator can be used to visualize data regardless of whether data exists in bins

*** # Advanced Queries *** ## Advanced Queries In this section, we'll cover some advanced operators used in KQL queries, to help you begin exploring data in Tricloud Nexus. *** ### series\_fit\_line operator (Trend line) The Query below demonstrates the usage of the *series\_fit\_line* operator. The *series\_fit\_line* operator performs a linear regression analysis on the time series data. It determines the direction and strength of a trend in the AvgValue series over time. The key output, the TrendLine, provides a smoothed linear approximation of the data, which helps identify patterns or predict future behavior. ```kusto let startTime = datetime("2024-10-01 00:00:00"); let endTime = datetime("2025-01-01 00:00:00"); let resolution = 1d; let tagName = "DA.IM.P103.Line.OrderCompletion"; Measurements | where StartTimestamp > startTime and StartTimestamp < endTime | where HierarchicalName has tagName | extend properties = todynamic(ValueString) | extend DeliveredItems = toint(properties.deliverQuantiy) | make-series AvgValue = avg(DeliveredItems) default=0 on StartTimestamp from startTime to endTime step totimespan(resolution) | extend (RSquare,Slope,Variance,RVariance,Interception,TrendLine)=series_fit_line(AvgValue) | render timechart ``` Looking at the raw result of the query, it shows the AvgValue and TrendLine as an Array of values, that can be plotted to a timeChart and will show the AvgValue and Trend of the delivered items. However using the *series\_fit\_line* also returns other metrics like RSquare, Slope, Variance, RVariance as seen below:
Here's an explanation of the key metrics from the query result: #### **RSquare (R²):** * **What it measures:** The proportion of the variance in the observed data (`AvgValue`) that is explained by the trend line (`TrendLine`). * **Value in the result:** `0.7435` (approximately 74%). * **Interpretation:** About 74% of the variability in the daily average delivered items can be explained by the trend line. This indicates a relatively good fit but leaves room for unexplained variation due to other factors or noise. #### **Slope:** * **What it measures:** The rate of change of the trend line over time. * **Value in the result:** `0.6919`. * **Interpretation:** The daily average number of delivered items is increasing at a rate of approximately `0.69` units per day. This indicates a consistent upward trend in deliveries over the analyzed time period. #### **Variance:** * **What it measures:** The variability or spread of the observed data (`AvgValue`). * **Value in the result:** `459.1032`. * **Interpretation:** The observed data has a moderate level of variability, showing fluctuations in the daily delivery averages over time. A high variance typically indicates significant day-to-day changes in deliveries. #### **RVariance (Residual Variance):** * **What it measures:** The variance of the residuals, which are the differences between the observed values (`AvgValue`) and the predicted values on the trend line (`TrendLine`). * **Value in the result:** `117.7715`. * **Interpretation:** This is the portion of variance in the observed data that is not explained by the trend line. The residual variance is significantly smaller than the total variance, which supports the relatively good R² value and indicates that the trend line captures most of the data's pattern. #### **Interception:** * **What it measures:** The y-intercept of the trend line, representing the predicted value of `AvgValue` when the x-axis (time) starts (e.g., the first day of the time period). * **Value in the result:** `-12.6436`. * **Interpretation:** The trend line predicts an initial value of approximately `-12.64` for the first day, which is not physically meaningful in this context (as deliveries cannot be negative). This suggests that the trend line is more relevant for capturing the overall slope and pattern rather than precise starting values. Here is the result of running the Query and rendering it using the timeChart:

The trend of a timeseries can be calculated using the series_fit_line operator

*** ### Series\_decompose\_forecast operator In the following example the *series\_decompose\_forecast* operator is used to forecast the average value of the delivered items of workorders 1 week into January 2025, based on average values from December month of 2024. In the make-series operator, we are extending the end time by 7 days to include space for the forecasted points. ```kusto let startTime = datetime("2024-12-01 00:00:00"); let endTime = datetime("2024-12-31 00:00:00"); let resolution = 1d; let tagName = "DA.IM.P103.Line.OrderCompletion"; let forecast_points=7; Measurements | where StartTimestamp > startTime and StartTimestamp < endTime | where HierarchicalName has tagName | extend properties = todynamic(ValueString) | extend DeliveredItems = toint(properties.deliverQuantiy) | make-series AvgValue = avg(DeliveredItems) default=0 on StartTimestamp from startTime to (endTime + forecast_points*resolution) step totimespan(resolution) | extend Forecast = series_decompose_forecast(AvgValue, forecast_points) | render timechart ``` Here is the result of running the Query. The Average DeliveredItems is shown per. day, and the Average DeliveredItems is forecasted 7 days into January.

The series_decompose_forecast operator can be used to forecast future values of a timeseries

*** # Designer The **Designer** area of Tricloud Nexus is your central workspace for building and configuring the digital twin of your operations. It provides powerful tools to help you design, organize, and maintain every aspect of your IIoT or industrial environment - from the physical asset hierarchy down to software modules and integrations.

Module Store of the Designer

*** ### Key Features * **Asset Hierarchies**\ Model your plant, site, or entire organization using flexible asset hierarchies. Align your digital representation with real-world equipment, processes, and logical groupings according to standards like ISA-95 - or use custom structures that fit your business. * **Asset Modeling**\ Define, organize, and manage all physical and logical assets, from machines and production lines to sensors and software-defined areas. Define Tags/Data points and configure Read and Write operations through data connectors. Attach properties, metadata, and tags for contextualized data and smarter analytics. * **Data Connectors**\ Configure and manage connections to field equipment, PLCs, sensors, data historians, and other industrial systems. Data Connectors ensures a standardized output format for a robust, scalable data integration. You can build and import your own data connectors using our SDK. * **Module Store**\ Import, register, and manage reusable modules or containers (such as analytical modules, protocol gateways, data connectors, and processing logic). Maintain a library of trusted modules ready for deployment. You can import your own modules as well as any 3rd party docker module. * **Application Configuration**\ Build and configure applications by combining imported modules with configuration. Applications can be tailored to specific use cases, devices, or production environments and are versioned and can be updated from the update center. * **Versioning**\ Manage versions of your asset hierarchies, modules, and applications to ensure controlled rollouts, auditability, and repeatability across sites or devices. * **Import/Export & Automation**\ Import existing models, export configurations for backup or replication, and automate repetitive setup tasks. ### Why Use Designer? * Centralizes the design and management of your entire IIoT environment. * Empowers teams to digitize operations, accelerate integration, and maintain data consistency. * Supports both simple and advanced scenarios - from small machine shops to global multi-site enterprises. *** **In summary:**\ The Designer area is where you bring your digital operations to life - structuring your assets, configuring data flows, and assembling modular applications for deployment at the Edge or in the cloud. Whether you’re onboarding a new site, building a data pipeline, or customizing industrial applications, Designer gives you the tools you need to innovate and scale with confidence. # Assets *** The **Assets** section in Designer is where you define, organize, and manage the physical and logical structure of your operations. This area provides a flexible framework for modeling your plant, site, production lines, equipment, and other assets, enabling powerful contextualization of your data and seamless integration with industrial standards.

Modelling Assets using Designer

Within the **Assets** section, you’ll find tools for modelling detailed hierarchies, configuring properties and tags, managing data connections, and maintaining control over asset versions and structure. This forms the configuration needed for all device deployments in Tricloud Nexus. ### Key Features #### Asset Hierarchies Model the real-world structure of your organization or facility using customizable asset hierarchies. Easily map physical sites, areas, production lines, and machines to their digital twins. Support for standards like ISA-95 ensures interoperability and consistent organization across all your projects. #### Data Connectors Configure and manage connections to your industrial equipment and data sources. Data connectors allow you to integrate with a wide range of protocols and platforms, such as OPC UA, Modbus, MQTT, FTP, File Shares, and more. These connections form the backbone for reliable data acquisition and control. #### Tags Tags are the individual measurement points and control signals that bring your assets to life. In Tricloud Nexus, you can organize, configure, and enrich tags to enable precise data collection, processing, and storage. Define custom measurement types, sampling intervals, scaling factors, and metadata to suit your specific operational requirements. Tag values can be **read** from data connectors for monitoring and analytics, or **written** back to equipment for automated control- enabling bidirectional data flows throughout your asset hierarchy. #### Models Deploy and manage analytical or machine learning models directly within your asset hierarchy, hosting them as containers at the Edge. Seamlessly configure input and output tags to connect your models with live operational data. This allows your asset hierarchy to provide real-time inputs to your models, process their outputs, and store results efficiently - unlocking advanced analytics, automation, and decision support at the Edge of your operations. *** ### Summary The **Assets** area empowers you to create a comprehensive digital representation of your operations, making it easy to contextualize data, ensure data quality, and enable advanced analytics and automation throughout your IIoT ecosystem. # Asset Hierarchies *** The **Asset Hierarchies** section is where you define the overall structure of your operations in Tricloud Nexus. An asset hierarchy is a digital map of your physical or logical environment, capturing the relationships between different parts of your plant/sites or organization. It provides the foundation for contextualizing data, organizing assets, and enabling scalable, consistent deployments across your IIoT landscape. ### What is an Asset Hierarchy? An asset hierarchy represents the structured organization of your assets and equipment. By creating a hierarchy, you can model how your operations are organized in the real world - supporting everything from high-level enterprise sites down to individual machines and sensors. Asset hierarchies are essential for ensuring data consistency, enabling analytics, and streamlining deployments. {% hint style="info" %} It’s often a good practice to create a separate asset hierarchy for each site, as no two sites are ever exactly alike in terms of equipment, production lines, or asset configurations. For smaller installations, however, it may be more practical to maintain a single asset hierarchy that covers all assets. {% endhint %} Here is a simple example of an Asset Hierarchy that models a single site called Dallas Factory: ![](/files/QJ6WAaxLAjTQzHJq9J6u) The Asset Hiearchy follows the [ISA 95 structure](/management-portal/designer/assets/asset-hierarchies/isa-95): * **Dallas Factory** (ISA95 - Site) - *Root Node* of the hierarchy * **Injection Molding** (ISA95 - Area) - An *Area* within the factory where Injection Molding takes place * **Press 103** (ISA95 - Line) - An *Area* in injection molding area that contains the Press 103 Line * **Stamper** (ISA95 - Cell) - An *Asset* of the Press 103 Line called Stamper. This is an actual machine/equipment containing sensors and data that can be read or written to * **Conveyor Belt** (ISA95 - Area) - An *Area* in injection molding area containing a conveyor belt * **Cooling Storage** (ISA95 - Area) - Another *Area* in the injection molding area containing Cooling facilities for the produced goods * **Lab** (ISA95 - Area) - Another *Area* within the factory that contains a Lab responsible for Quality Control (QC) *** ### Nodes Every Asset Hiearchy has a [Root Node](/management-portal/designer/assets/asset-hierarchies/settings-and-versioning#versioning-of-asset-hierarchies) that contains audit information about the [version](/management-portal/designer/assets/asset-hierarchies/settings-and-versioning#hierarchy-settings) of the hierarchy as well as letting you define a data store for the measurements of the hierarchy. Besides the root node, there are generally two types of nodes in an Asset Hierarchy; namely [Areas](/management-portal/designer/assets/asset-hierarchies/areas) and [Assets](/management-portal/designer/assets/asset-hierarchies/assets). * **Areas** - Area nodes are used to represent distinct zones or sections within your organization, such as sites, lines, departments or production areas. You can configure [**Data Connectors**](/management-portal/designer/assets/data-connectors) at the area level to establish connectivity with equipment within the area. Additionally, areas enable you to define [**Jobs**](/management-portal/designer/assets/jobs) for establishing workflows for files at Edge using FTP or FileShare protocols. * **Assets** - Asset nodes represent individual pieces of equipment or logical assets within your organization. On asset nodes, you can configure [**Tags**](/management-portal/designer/assets/tags), which serve as identifiers for reading from, or writing to data connectors. Tags have a [**Measurement Type**](https://github.com/triclouddk/tcnexus-iotplatform-docs/blob/main/management-portal/designer/assets/asset-hierarchies/broken-reference/README.md) that can be Analog (numeric values), Digital (boolean), or String (text or JSON). Tag configuration is organized into sections for collecting, processing, and storing data.\ Asset nodes also allow you to host and configure custom [**Models**](https://github.com/triclouddk/tcnexus-iotplatform-docs/blob/main/management-portal/designer/assets/asset-hierarchies/broken-reference/README.md) (containers), connecting them to live operational data through input and output tags. Both types of Nodes contains the possibility to add descriptions and [**Meta Data**](/management-portal/designer/assets/asset-hierarchies/meta-data) to the Area, Asset or Tag. Any meta data added to the nodes or tags will be [**available** ](/management-portal/insights/queries/creating-a-query/intermediate-queries)in the time series database upon deployment, ensuring that all contextual information is readily available for analysis and reporting. {% hint style="info" %} Child Nodes can be ordered within its parent using drag-n-drop. Dragging nodes to other nodes in the hierarchy is currently not supported. {% endhint %} *** ### Creating Asset Hierarchies Creating a new asset hierarchy is simple: 1. **Navigate to the Asset section** within Designer 2. Click **New Hierarchy** which opens the Create Asset Hierarchy dialog

Create Asset Hierarchy dialog

3. Provide a *name* and, optionally, a *description* for your asset hierarchy. You can also select a *data store*, which determines where the asset hierarchy and its metadata will be synchronized. The selected data store also defines where all associated measurements can be ingested.\ **Click Create** to create the hierarchy 4. An empty asset hierarchy is created. You can build your hierarchy from scratch, or [import ](#importing-and-exporting-hierarchies)an exsisting asset hierarchy to use as a starting point 5. As you build your hierarchy, you can save your progress at any time, in which case the [version](/management-portal/designer/assets/asset-hierarchies/settings-and-versioning) of the hierarchy increases 6. If you make a mistake, you can always use the Asset Hierarchy selection drop down to select a previous version of the hierarchy, and continue to make changes. When you are happy just click Save again.

The Asset hierarchy selection dropdown

> **Tip:** You can create multiple asset hierarchies to represent different sites, projects, or logical environments. *** ### Adding Nodes to Asset Hierarchy When you create a new asset hierarchy - or select an existing one from the dropdown at the top of the page - you can build your hierarchy by adding nodes to the tree structure. 1. **Right click on a Node** or **left click the actions menu** of a node to bring up a context menu with node actions

The Node actions menu

2. In the context menu, you can select **Add Area** or **Add Asset** to add a child node to the currently selected node of either type Area or Asset. Additionally you can use the menu, to **rename** the selected node, **select an icon** to represent the node or **delete the selected node** 3. **Adding or Renaming** a node puts the node into edit mode, and lets you specify a name for the Node

Specifying a name for the node

### Importing and Exporting Asset Hierarchies Tricloud Nexus supports importing and exporting asset hierarchies, allowing you to: * **Import** existing hierarchies from allready exported hierarchy file (zip format) for rapid onboarding or migration from other systems. * **Export** your asset hierarchy for backup, replication, or deployment to other environments. This makes it easy to manage your hierarchies across projects, collaborate with other teams, or maintain consistent structures in multiple locations. #### Importing an Asset Hierarchy 1. To import an Asset Hierarchy simply click the **Actions** menu and select **Import** in the dropdown menu.
2. The import Asset Hierarchy Dialog will appear.
3. **Click Browse** to navigate and select an Asset Hierarchy file to import 4. Select whether to import the Asset hierarchy as a **new hierarchy** or import it into an **exsisting hierarchy** (The currently selected hierarchy). In the above example, its chosen to import the hierarchy as a new hierarchy called 'Oregon Factory' 5. Select the **Data store** to use for the data of the hierarchy (meta data and measurements) 6. **Click the Import** button, and the hierarchy is imported #### Exporting an Asset Hierarchy 1. To export an Asset Hierarchy you must first **select the Hierarchy to Export** in the Asset Hierarchy selection drop down. 2. Then simply click the **Actions** menu and select **Export** in the dropdown menu.
2. The Export Asset Hierarchy dialog will appear

Export Asset Hierarchy dialog

3. **Select the Version** you want to export 4. **Type the filename** you want to use 5. **Click the Export button** and the hierarchy is exported

The hierarchy is exported

3. **Click and download** the hiearchy export file to your environment ### Validate and Save Hierarchies At any point during editing, you can **validate** your asset hierarchy to ensure structural integrity and catch configuration errors before deployment. Validation helps maintain high data quality and avoids issues downstream. You can also **save** your hierarchy at any stage of the process, letting you work iteratively and collaborate with confidence. #### Validate Asset Hierarchy To validate a hierarchy first select the hierarchy to validate then simply **click the Validate button** which brings up the validation dialog. If the hierarchy in its current version cannot be validated, configuration issues will appear in the dialog.

Validation errors are shown if validation of hierarchy failed

Upon closing the the dialog, the Management Portal will hightlight where the **validation errors** are located in the hierarchy, by marking the Tree nodes, Tabs, Rows and details with red text. This makes it easier to locate and fix any validation issues.

Validation errors being marked with red in the Asset Hierarchy

Once the validation errors are fixed, running another vlidation check should show no errors.

Validation check passed

#### Save Asset Hierarchy You can also **save** your hierarchy at any stage of the process, letting you work iteratively and collaborate with confidence, simply by **clicking the Save button**, which brings up the Save Asset Hierarchy dialog.

Save Asset Hierarchy dialog showing validation errors

A validation of the entire asset hierarchy is performed in the dialog, and any **validation errors will be displayed**. Asset Hierarchies can be saved, even though they contain validation errors, but they cannot be deployed to a device. A **save comment can be added** in the Save dialog, which will appear as comments in the hierarchy revisions ([versioning](/management-portal/designer/assets/asset-hierarchies/settings-and-versioning)) of the hierarchy. # Settings and Versioning Every Asset Hierarchy in Tricloud Nexus includes a **Root Node**, which contains key hierarchy settings and revision (versioning) information. ### Hierarchy Settings When you select the root node of any asset hierarchy, you gain access to settings that define the identity and data context of the hierarchy. The following properties can be configured: Settings that can be edited include: * **Name** The display name of the Hierarchy * **Alias** An optional [ISA-95 Alias](/management-portal/designer/assets/asset-hierarchies/isa-95) to use for the root node. Aliases are used in hierarchical tag naming conventions. * **Description** Optionally provide a description for the hierarchy to clarify its purpose or scope. * **Data Store** Select the [data store](/management-portal/platform-settings/data-stores) where the asset hierarchy and all associated metadata will be synchronized. The chosen data store also determines where all measurement data will be ingested. \\

Settings of the Asset Hierarchy

### Versioning of Asset Hierarchies At any point during editing, you can [validate and save](/management-portal/designer/assets/asset-hierarchies#validate-and-save-hierarchies) your asset hierarchy to ensure structural integrity and catch configuration errors before deployment. All asset hierarchies in Tricloud Nexus are versioned. Each time you save changes, a new version is saved in the Hierarchy Revisions section, allowing you to: * Track changes and maintain a history of your hierarchy over time. * Roll back to previous versions if needed. * Audit modifications for compliance and troubleshooting. Versioning provides robust change management, ensuring you always have control and visibility over the configuration of your digital environment. #### Accesssing Hierarchy Revisions You can find the Hierarchy Revisions by selecting the root node of the hierarchy. Hierarchy revisions should appear in the right panel of the screen:

Hierarchy Revisions shows who made changes to the hierachy and shows comments for every save action

{% hint style="info" %} You can use the 'Search changelogs' textbox of the Hierarchy Revisions table, to search for changes made by specific users, or specific comments that were added in a previous version of the asset hierarchy. {% endhint %} The panel in the right side also contains a Tab called Properties, that allows you to add additional [Meta data properties](/management-portal/designer/assets/asset-hierarchies/meta-data) for your Asset Hierarchy. #### Roll back to previous version If you need to revert to an earlier configuration (earlier version of the Asset Hierarchy) * Use the **Asset Hierarchy selection dropdown** to choose a previous version.

The Asset hierarchy selection dropdown

* Make any necessary adjustments, then **click** **save** to create a **new revision**. This flexible approach ensures you always have control and visibility over your digital environment and can confidently manage changes as your operations evolve. # Areas The **Areas** node is a core building block in any [asset hierarchy](/management-portal/designer/assets/asset-hierarchies). Areas are used to model the logical or physical zones that make up your operation - such as sites, departments, production lines, rooms, or any other organizational level relevant to your business. By structuring your hierarchy with nodes of type *Area*, you can accurately reflect your real-world organization, making it easy to contextualize data, manage access, and maintain clear separation of equipment and workflows. *** ### What is an Area? An **Area** is a node type designed to represent a distinct section of your environment within an asset hierarchy. Areas help you group related assets, equipment, and data flows under a common context. For example, in a manufacturing facility, you might create Areas for each production line, packaging zone, or quality lab. Areas are not limited to physical locations - they can also be used for logical segmentation, such as separating test and production zones, or grouping equipment by process or function. ### Key Features of Areas * **Hierarchical Organization** Areas can be nested, allowing you to build multi-level structures (e.g., Site → Building → Production Line). * **Data Connectors** Configure [data connectors](/management-portal/designer/assets/data-connectors) directly on an Area node to establish connectivity with the equipment or subsystems within that area. This ensures data collection is logically organized and managed at the appropriate level. * **Job Configuration** Define [jobs ](/management-portal/designer/assets/jobs)at the Area level to automate workflows such as moving files from the edge to custom modules for processing or move the files to the cloud using supported protocols (e.g., FTP or FileShare). Jobs can also be used to transfer files from the Cloud to Edge and the production floor. * **Meta data and Description** Add descriptions and custom meta data to any Area, ensuring all contextual information is available throughout the platform and as contextual information in the time series database. * **Flexible Grouping** Use Areas to isolate environments for security, reporting, or deployment - such as separating by customer, department, or use case. *** ### Example A typical hierarchy with Areas might look like this: ``` - Copenhagen Plant (Area) - Packaging Line 1 (Area) - Labeler (Asset) - Conveyor (Asset) - Quality Lab (Area) - Test Bench 1 (Area) ``` Areas are the foundation for organizing your digital twin, enabling scalable asset management, clear data flows, and flexible deployment across your IIoT landscape. *** ### Creating an Area Node To add an Area to your Asset Hierarchy: 1. **Right click on a Node** or **left click the actions menu** of a node to bring up a context menu with node actions

The Node actions menu

2. In the context menu, you can select **Add Area** to add a child node of type *Area* to the currently selected node. Additionally you can use the menu, to **rename** the selected node, **select an icon** to represent the node or **delete the selected node** 3. **Adding or Renaming** a node puts the node into edit mode, and lets you specify a name for the Node You can continue to add child Areas or Assets within any Area node, allowing you to build a detailed, multi-level representation of your operation. *** ### Set Area Information In the **Area Info** tab, you can provide key details that define and identify your Area: * **Area Name** The display name for the Area as it will appear throughout the hierarchy. * **ISA-95 Alias** An optional alias used to influence how tags for child assets are named, in alignment with the ISA-95 standard. For example, setting the alias to `S1` will result in any child Tags being named as `AE.S1.A1.Tag1`. Refer to the [ISA-95 documentation](/management-portal/designer/assets/asset-hierarchies/isa-95) for further details. * **Icon** Choose a custom icon to visually represent the Area node, making the hierarchy easier to navigate and interpret. * **Description** Optionally add a description for the Area. This description provides additional context and is stored in the time series database, enhancing the traceability and documentation of your digital environment.

The Area info Tab lets you specify Alias for ISA 95 structure as well as a description for the Area

*** ### Set Meta data for Area You can add additional contextual information to the Area using [Meta data](/management-portal/designer/assets/asset-hierarchies/meta-data) which can be added as key/value parameters. 1. Select the **Area** node in asset hierarchy 2. Make sure you select the **Area info** tab of the Area 3. The Meta data dialog will appear on the right side of the page 4. **Click Add property** and specify a Property name and Value then **click the Save** icon

Meta data is added to an Area, in this example the physical address of the Site

{% hint style="info" %} Metadata for all nodes and tags is automatically made available in the time series database after the hierarchy is deployed. For guidance on accessing and querying this metadata, please refer to the [Intermediate Queries](/management-portal/insights/queries/creating-a-query/intermediate-queries) section. {% endhint %} *** ### Best Practices * Model your organization as you would describe it to a new employee or partner - each Area should reflect a logical grouping that makes sense for navigation, reporting, and access control. * Use Areas to separate different physical locations, lines, departments, or operational functions for maximum clarity. * Add metadata to Areas to enhance data contextualization and simplify later analysis or integration. # Assets The **Asset** node is a core building block in any [asset hierarchy](/management-portal/designer/assets/asset-hierarchies). Assets are used to represent the actual equipment, machines, or logical entities that are part of your operations. Assets are the heart of your digital twin, capturing real-world devices and connecting them to your data infrastructure. Structuring your hierarchy with Asset nodes lets you precisely model, monitor, and interact with the physical and logical components that drive your business. *** ### What is an Asset? An **Asset** is a node type in your asset hierarchy used to model individual machines, devices, or logical units - such as pumps, sensors, controllers, or even software services. Assets are typically located under an Area, and each asset node contains the information, configuration, and data points (Tags) necessary for integration and operation. By modeling assets within the hierarchy, you create a one-to-one relationship between your real-world equipment and its digital representation, enabling precise tracking, control, and analytics. ### Key Features of Assets * **Tag Configuration** Assets are where you define and [manage tags](/management-portal/designer/assets/tags) - measurement points or control signals representing sensor values, setpoints, statuses, or commands. Tags can be analog (numeric), digital (boolean), or string (text or JSON). You can further organize tag settings in sections for collection, processing, and storage. * **Custom Models** Asset nodes support the deployment of [custom models](https://github.com/triclouddk/tcnexus-iotplatform-docs/blob/main/management-portal/designer/assets/asset-hierarchies/broken-reference/README.md) or containers (such as analytics or machine learning modules) at the edge. You can configure input and output tags to connect your models to live operational data, enabling advanced processing and automation at the asset level. * **Metadata and Description** Add detailed descriptions and custom metadata to each asset, making contextual information available in the time series database for improved traceability, analysis, and reporting. * **Flexible Placement** Assets can be added as child nodes under any Area, giving you the flexibility to represent simple or complex environments - whether a single device or an entire fleet of machines. Assets can also be nested under other assets, allowing you to model complex equipment structures with sub-assets when needed. *** ### Example A typical hierarchy with Assets might look like this: ``` - Copenhagen Plant (Area) - Packaging Line 1 (Area) - Labeler (Asset) - Conveyor (Asset) - Vibration Sensor (Asset) - Quality Lab (Area) - Test Bench 1 (Asset) ``` *** ### Creating an Asset Node To add an Asset to your asset hierarchy: 1. **Right click on a Node** or **left click the actions menu** of a node to bring up a context menu with node actions

The Node actions menu

2. In the context menu, you can select **Add Asset** to add a child node of type *Asset* to the currently selected node. Additionally you can use the menu, to **rename** the selected node, **select an icon** to represent the node or **delete the selected node** 3. **Adding or Renaming** a node puts the node into edit mode, and lets you specify a name for the Node You can continue to add child Assets or even sub-assets within an Asset node, allowing you to build detailed digital representations of your physical equipment. *** ### Set Asset Information In the **Asset Info** tab, you can provide key details that define and identify your Asset: * **Asset Name** The display name for the Asset as it will appear throughout the hierarchy. * **ISA-95 Alias** An optional alias used to influence how Tags for this Asset or child assets are named, in alignment with the ISA-95 standard. For example, setting the alias to `A1` will result in any child Tags being named as `AE.S1.A1.Tag1`. Refer to the [ISA-95 documentation](/management-portal/designer/assets/asset-hierarchies/isa-95) for further details. * **Icon** Choose a custom icon to visually represent the Asset node, making the hierarchy easier to navigate and interpret. * **Description** Optionally add a description for the Asset. This description provides additional context and is stored in the time series database, enhancing the traceability and documentation of your digital environment.

The Area info Tab lets you specify Alias for ISA 95 structure as well as a description for the Area

*** ### Set Meta data for Asset You can add additional contextual information to the Asset using [Meta data](/management-portal/designer/assets/asset-hierarchies/meta-data) which can be added as key/value parameters. 1. Select the **Asset** node in asset hierarchy 2. Make sure you select the **Asset info** tab of the Area 3. The Meta data dialog will appear on the right side of the page 4. **Click Add property** and specify a Property name and Value then **click the Save** icon

Meta data is added to an Asset, in this example an EquipmentId and LastinspectionDate

{% hint style="info" %} Metadata for all nodes and tags is automatically made available in the time series database after the hierarchy is deployed. For guidance on accessing and querying this metadata, please refer to the [Intermediate Queries](/management-portal/insights/queries/creating-a-query/intermediate-queries) section. {% endhint %} *** ### Best Practices * Use clear, descriptive names for each asset to ensure the hierarchy is easy to navigate. * Add meaningful descriptions and metadata to Assets to enhance traceability and future analysis. * Configure tags to match your operational needs, ensuring data is accurate and actionable. * Deploy custom models on assets that require advanced local analytics or automation. # ISA-95 The **ISA-95 standard** is the foundation for organizing and naming assets, areas, and tags. ISA-95 is an internationally recognized standard for the integration of enterprise and control systems, widely adopted in manufacturing and industrial environments. By following this structure, you can ensure consistency, interoperability, and scalability across your digital twin and IIoT deployments. ### Benefits of Using ISA-95 * Establishes a universal language for system integration and asset management. * Supports scalable, maintainable hierarchies across multiple plants, sites or projects. * Enables faster onboarding and easier communication between IT, OT, and business teams. * Simplifies data analysis, reporting, and cross-system interoperability. *** ### The ISA-95 Hierarchical Model ISA-95 defines a clear, hierarchical structure for representing your organization and its operations. Each level serves a distinct role, supporting organized information flow and activity from top-level business functions down to the shop floor. **Hierarchy Overview:** ``` Enterprise └── Site └── Area └── Line └── Cell ``` * **Enterprise** The highest level, representing your entire company or organization. This encompasses all sites and their associated areas. This typically correlates to the Root Node of your Asset Hierarchy. * **Site** A specific physical location where manufacturing operations take place, such as a factory or plant. Each site can contain multiple areas. * **Area** A defined section within a site focused on a particular manufacturing process, product, or function (e.g., a production hall, packaging area, or QC lab). * **Line** Represents a production line within an area - such as an assembly or filling line. * **Cell** The lowest level, representing individual machines, work cells, or equipment that carry out specific tasks. This hierarchical structure allows for a clear and organized flow of information and activities from the top-level business functions down to the shop floor, facilitating better communication and coordination between different levels of the organization. *** ### Applying ISA-95 in Tricloud Nexus When building your asset hierarchies in Tricloud Nexus, the ISA-95 structure guides how you organize and name your sites, areas, lines, and assets. Mapping your hierarchy to ISA-95 levels enables your digital model to accurately reflect your physical organization, supporting advanced analytics and reliable integration with external systems. #### Example ISA-95 Structure ``` Acme Corporation (Enterprise) └── Dallas Factory (Site) └── Injection Molding (Area) └── Press 103 (Line) └── Stamper (Cell/Equipment) ``` #### Using ISA-95 Structure to model Asset Hierarchy The example of an ISA-95 structure for Acme Corporation can be modelled in an Asset Hierarchy using the following Nodes: ``` Acme Corporation (Root Node) └── Dallas Factory (Area) └── Injection Molding (Area) └── Press 103 (Area) └── Stamper (Asset) ``` Applying this structure to an actual Asset Hierarchy will look like this:

ISA-95 strructured Asset Hierarchy for Acme Corporation

*** ### ISA-95 Alias & Naming Conventions Tricloud Nexus leverages the ISA-95 model and enables you to assign **aliases** at every node level - Root, Area or Asset - to generate short, descriptive, and consistent tag names across your organization. #### Tag naming without Aliases Suppose you create a tag called `Temp` on the **Stamper** asset. If you rely solely on the full node names, your tag’s hierarchical name might look like this: ``` Acme Corporation/Dallas Factory/Injection Molding/Press 103/Stamper/Temp ``` While this structure is human-readable and preserves context, the tag name is lengthy and can be cumbersome in analytics reports or dashboards. #### Tag naming with Aliases A more concise and effective approach is to assign **aliases** to each node, using periods (`.`) as separators. This maintains the context, but keeps tag names readable and compact. For example: ``` DA.IM.P103.S01.Temp ``` Where: * **DA** = Dallas Factory * **IM** = Injection Molding * **P103** = Press 103 * **S01** = Stamper * **Temp** = Tag Name In this example, the root-level alias (e.g., Acme Corporation) is omitted for clarity, but including it is optional. The key benefit is clear, standardized, and manageable tag names that retain essential context. The Hierarchical Name can be read in the following way: ``` DA.IM.P103.S01.Temp Dallas Factory (DA) └── Injection Molding (IM) └── Press 103 (P103) └── Stamper (S01) └── Tag (Temp) ``` *** ### How Hierarchical Names for Tags are Generated Tag names in Tricloud Nexus are **automatically generated** based on their position in the hierarchy and the aliases set on each parent node. This means every tag gets a unique, contextual name without manual editing. * By default, a node’s alias is based on its name (with special characters and spaces removed). * You can [set or change the alias](#set-isa-95-alias-for-hierarchy-nodes) for any node - Root, Area, or Asset - via the Info tab (or hierarchy settings for the root). * Aliases are required for all Areas and Assets; the root node alias is optional. {% hint style="info" %} Tag names are automatically generated and applied to all Tags in the Hierarchy based on the Tags location in the Hierarchy and Aliases specified for all parent nodes. {% endhint %} *** ### Set ISA-95 Alias for Hierarchy Nodes Whether the Node is a Root, Area or Asset node, you can define an ISA-95 Alias for the Node. 1. **Select the Node** you want to define an Alias for 2. **Go to** the Area/Asset **info Tab** (or hierarchy settings for Root node) 3. Specify the **Alias** in the textbox
Using Aliases ensures every Tag is uniquely identified based on its location in the hierarchy, making integration, reporting, and troubleshooting straightforward. {% hint style="info" %} By default the Alias is the same as the Name of the Node (but any special chracters like @£$€€{\[\[]]Space are removed) Setting an Alias on the Root Node is optional, but Aliases are required on all [Areas ](/management-portal/designer/assets/asset-hierarchies/areas)or [Assets](/management-portal/designer/assets/asset-hierarchies/assets). {% endhint %} #### Hierarchical Tag Naming When a Tag is created on an [Asset](/management-portal/designer/assets), the **Hierarchical Name** of the Tag is automatically calculated. The Hierarchical Name is the ISA-95 naming of the Tag.

The Hierarchical Name is calculated based on Aliases of nodes in the Hierarchy

In addition to the hierarchical name, each tag is assigned a unique **Id** (GUID). If you change a node’s alias or rename a tag, the hierarchical name will update automatically - but the tag’s Id remains unchanged. {% hint style="info" %} When building [dashboards](/management-portal/insights/dashboards) or reports, it’s best to reference Tags by their **Id** (Cloud Id). This ensures your visualizations remain robust, even if names or aliases change in the hierarchy. Using the Hierarchical Name may render your Dashboard [Tiles ](/management-portal/insights/dashboards/create-a-dashboard/add-tiles)broken, if an Alias was changed in the hierarchy. {% endhint %} *** ### Best Practices * **Align your hierarchy with ISA-95 levels** to mirror your actual business and production structure. * **Map your environment faithfully** from enterprise down to individual machines or sensors - to enable clear navigation and analytics. * **Use meaningful Aliases** Assign clear, concise aliases to every Area and Asset node to generate standardized, readable tag names. * **Design for scalability and integration** A standardized hierarchy makes it easy to expand or connect new systems in the future. * **Dashboards** Use the hierarchical name for context, but rely on the Id of the measurements for integration, reporting, and dashboarding.\\ # Meta Data **Meta data** in Tricloud Nexus allows you to enrich every part of your asset hierarchy with valuable context. Meta data properties can be added to any node - [**Areas**](/management-portal/designer/assets/asset-hierarchies/areas)**,** [**Assets**](/management-portal/designer/assets), or even individual [**Tags**](/management-portal/designer/assets/tags) - to describe your environment in detail, enable smarter analytics, and support integration with external systems. *** ### Why use Meta Data? Adding meta data helps you: * Capture important details that go beyond names and hierarchy - such as equipment type, location, vendor, maintenance dates, asset owner, and more. * Improve search, reporting, and filtering across your digital twin. * Enable advanced analytics and automated processes by making contextual information available everywhere in the platform. For instance by adding Unit of Measure to your Tags, you gretly help any future stakeholder understand the measurements. *** ### Where can Meta Data be applied? You can add custom meta data properties to: * **Any Node:** [Root](/management-portal/designer/assets/asset-hierarchies/settings-and-versioning), [Area](/management-portal/designer/assets/asset-hierarchies/areas), or [Asset ](/management-portal/designer/assets)nodes can all have meta data. * **Tags:** Each [Tag](/management-portal/designer/assets/tags) (measurement point or control signal) can have its own set of meta data for even more granular detail. *** ### How to Add Meta Data 1. **Select the Node or Tag** where you want to add meta data in the asset hierarchy tree. 2. Go to the **Info tab** (Area Info, Asset Info), for Tags you must select the **Store tab**. 3. Find the **Meta Data** section (usually a panel in the right side of the screen). 4. Click **Add Property**, enter a property name and value, then save.

Adding Meta data to an Area, in this example the physical address of the Site

{% hint style="info" %} You can add as many properties as needed to fully describe each element of your hierarchy. {% endhint %}
*** ### Accessing Meta Data Once your hierarchy is deployed, all meta data properties are automatically synchronized to the time series database. This means: * Meta data is always available for analysis, visualization, and queries - whether you’re troubleshooting, building dashboards, or integrating with other platforms. * You can query meta data directly. See the [Intermediate Queries](/management-portal/insights/queries/creating-a-query/intermediate-queries) section for detailed instructions on accessing meta data in your database or reporting tools. * Meta data properties are available to match the [version](/management-portal/designer/assets/asset-hierarchies/settings-and-versioning) of the hierarchy that is deployed. This means that all metadata revisions are availble in the database. {% hint style="warning" %} Meta data **only** become available in the time series database after a successfull deployment. {% endhint %} *** ### Best Practices * Use consistent property names and formats for easy filtering and reporting. * Add meta data for anything important to your operations - think about what you wish you could search for later! * Review and update meta data as your environment evolves to keep your digital twin accurate and useful. # Data Connectors **Data Connectors** are the bridges between your Tricloud Nexus environment and the equipment, sensors, and systems that generate operational data on your plant floor. **Every Data Connector runs on the Edge** and provides secure, reliable and real-time connectivity to local assets and systems.

The process of bringing data to cloud

Data connectors are used to connect to equipment in the physical world, so that these connectors may be used by [**Tags**](/management-portal/designer/assets/tags) to collect measurements using the Data Connectors. Data connectors can only be created and configured on [**Area** ](/management-portal/designer/assets/asset-hierarchies/areas)nodes within your [**Asset Hierarchy**](/management-portal/designer/assets/asset-hierarchies). This approach ensures that connectivity is mapped logically to your physical (or logical) layout, reflecting where and how your data is sourced and managed. *** ### What is a Data Connector? A Data Connector is a configuration that allows your Edge device to connect to external data sources or industrial protocols - right at the point where your operations take place. These connectors establish the communication pipeline between your plant floor equipment and Tricloud Nexus. Typical examples of supported Data Connectors include: * **MQTT** (for pub/sub data integration or integration with Unified Namespace) * **OPC-UA** (Industrial automation/control systems) * **Modbus** (TCP/RTU) * **FTP Server** or **FileShare** (for file workflows) * **Historian databases** (for storing processed measurements at the Edge) * **Emulator** (for test/simulated data) * **Custom Data Connectors** (Build your own data connector using C# and the Nexus SDK) All connections, authentications, and data flows configured with a Data Connector are executed at the Edge. This architecture provides local performance, improved security, and ensures data remains close to the source - perfect for industrial and IIoT environments. *** ### The role of Edge Data Connectors * **Edge-Based Integration:** All data connectors run locally on Edge devices, positioned at the Area level of your hierarchy, directly connecting to local equipment and networks. * **Protocol Translation and Unified Data Model:** Data Connectors act as protocol translators at the Edge, allowing you to connect to a wide variety of equipment and systems using different industrial protocols (such as OPC UA, Modbus, MQTT, and more). No matter which protocol is used on the equipment side, the Data Connector normalizes all incoming measurements into a unified Tricloud Nexus format. This ensures that data from any source is handled, processed, and stored consistently - both locally and in the cloud - enabling analytics, reporting, and integration across your IIoT environment. * **Offline Operation:** Data Connectors are designed to function even when your site or vessel loses internet connectivity. Since they run at the Edge, data can continue to be collected, processed, and stored locally. Once the internet connection is restored, all buffered data is automatically forwarded to the cloud or other destinations, ensuring no data is lost during offline periods. * **Logical Organization:** By attaching connectors to Areas, you ensure each data source is grouped by physical site, line, or process. * **Security & Compliance:** Data remains on-premises, traversing only secure, local connections. Access and permissions can be controlled per Area. * **Scalability:** Each Area in your hierarchy can have its own set of Edge data connectors, supporting multi-site and modular deployments. * **Data Contextualization:** Data is automatically organized and contextualized according to where (and how) it’s collected - streamlining analytics and reporting. *** ### Core Capabilities When you configure a Data Connector on an Area, you enable your Edge device to: * Collect data directly from local equipment or plant systems * Integrate industrial protocols and systems (MQTT, OPC-UA, Modbus, FTP etc.) * Support real-time and batch data flows between Edge and cloud * Centralize management of all local integrations and connections * Data Connectors are [monitored](/management-portal/operations/monitoring) and [alarms](/management-portal/operations/alarms) are raised if they are not working properly *** ### Typical Workflow

Adding a Data connector on the Dallas Factory Area

1. **Select an Area** in your asset hierarchy that corresponds to a physical part of your operation (such as a production line or department). 2. Navigate to the **Data Connectors** tab. 3. **Add a new Data Connector** by selecting the desired type (OPC-UA, Modbus, FTP, etc.) and provide a name for the connector.

Select a Data connector and provide a name for it

4. Enter the required connection details - these will be used by the Edge device at your site to connect to local equipment, and depends on the type of connector that was chosen in the previous step. 5. Save the configuration. The connector becomes active on the Edge upon deployment of the Asset Hierarchy. Additionally the data connector is available to all Assets and Tags that are childs of the Area. > **Note:** You can add multiple Data Connectors to a single Area, each one running independently at the Edge to support complex, heterogeneous environments. *** ### Next Steps See the following sections for detailed instructions on each supported Data Connector type: * [MQTT](/management-portal/designer/assets/data-connectors/mqtt) * [OPC-UA](/management-portal/designer/assets/data-connectors/opc-ua) * [Modbus TCP](/management-portal/designer/assets/data-connectors/modbus-tcp) * [ModBus RTU](/management-portal/designer/assets/data-connectors/modbus-rtu) * [Historian](/management-portal/designer/assets/data-connectors/historian) * [FTP Server](/management-portal/designer/assets/data-connectors/ftp-server) * [FileShare](/management-portal/designer/assets/data-connectors/file-share) * [Camera (Scene Controller)](/management-portal/designer/assets/data-connectors/camera-scene-controller) * [Emulator](/management-portal/designer/assets/data-connectors/emulator) * [Equation](/management-portal/designer/assets/data-connectors/equation) * [Custom Data Connectors](/management-portal/designer/assets/data-connectors/custom-data-connectors) Each guide explains configuration, best practices, and troubleshooting for its connector type - all focused on reliable Edge-to-equipment connectivity. # MQTT ## MQTT Data Connector The MQTT Data Connector enables Edge connectivity to equipment and systems that communicate using the MQTT protocol. Designed to run at the Edge, this connector supports both publishing and subscribing to MQTT topics, bridging your OT (Operational Technology) devices to your unified IIoT data model - regardless of local protocol differences. The **MQTT Data Connector** empowers Tricloud Nexus to integrate with a [Unified Namespace (UNS) architecture](/platform-architecture/unified-namespace) based on MQTT - regardless of whether the UNS operates locally on-site or at the enterprise level in the cloud. This approach enables consistent, real-time data exchange across your entire organization, breaking down silos and supporting a scalable, future-proof IIoT infrastructure. > **What is a Unified Namespace?**\ > A Unified Namespace is a central, structured, and real-time information model that brings together all operational and business data in one place - often implemented using MQTT for flexible, scalable connectivity.\ > Learn more about [Unified Namespace concepts](/platform-architecture/unified-namespace). ### Key Features * **Edge-Based Operation:** The MQTT connector runs locally on your Edge device, ensuring secure, real-time connectivity to equipment - even if your site loses internet connectivity. * **Flexible Topic Management:** Subscribe to (read) or publish (write) data on one or more MQTT topics. * **Payload Handling:** Supports JSON-formatted messages for rich, structured data exchange. * **Security:** Optional support for TLS and client authentication for secure data transfer. * **Automatic Data Normalization:** Converts incoming MQTT data to the Tricloud Nexus measurement format for unified storage and analytics. * **Offline Buffering:** Collect and buffer data locally during connectivity loss; forward all data once the connection is restored. * **Protocol Version Support:** Configure the connector for MQTT v3.1, v3.1.1, or v5.0. *** ### Configuring an MQTT Data Connector #### 1. Add a New Connector 1. Select an **Area** node in your asset hierarchy. 2. Go to the **Data Connectors** tab. 3. Click **+ New data connector** and choose **Mqtt Broker** and provide a **name** for the connector.

Add a new Data Connector

#### 2. Configure Connection Settings

Configuration of MQTT Connector

Fill out the connection details: * **Name:** Friendly name for this connector (e.g., `LocalUNS`). * **Broker Address:** IP or hostname of your MQTT broker (e.g., `123.10.10.142`). * **Broker Port:** Port number for the broker (usually `1883` for non-TLS, `8883` for TLS). * **Protocol Version:** Select the MQTT protocol version (`v5.0` recommended for new deployments). #### 3. Authentication & Security * **Username / Password:** (Optional) Enter if your broker requires authentication. * **TLS Enabled:** Toggle on to enable secure (encrypted) communication. * **TLS Protocol:** Choose supported TLS version (e.g., TLS 1.2). * **Validate Certificate:** Toggle on for strict server certificate validation. You must upload a certificate file in CER or CRT format, that can be used for validation. #### 4. Advanced: Send Connect Message Enable **Send Connect Message** to send custom parameters when establishing the MQTT connection. The connect message is the first MQTT packet/message sent by the client after the network connection between the client and the broker is established.\ \ You can specify the following values:\\ * **`clientId`** The clientId (for example, 'client-1') identifies each MQTT client connecting to an MQTT broker. If the clientId value is blank, an MQTT broker will still generate a unique parameter for this client to identify it. * **`cleanSession`** This parameter specifies whether a client wants to establish a persistent session with a broker or not. It can have the following values: * 'True' means a client doesn’t want to establish a persistent session (a broker will not save unsent messages if the connection is interrupted). In addition, all previous persistent sessions will get dismissed. * 'False' means a client wants to establish a persistent session * **`sessionExpiryInterval`** Defines how long a session can be retained on the server after a network disconnection. If the specified time elapses without reconnection, the server discards the session state. The values it can take are: * If unspecified or set to 0, the session ends immediately upon network disconnection. * If set to a value greater than 0, it specifies the number of seconds the session will be retained after disconnection. * If set to `0xFFFFFFFF`, the session will never expire. * **`keepAlive`** The MQTT keepAlive parameter identifies the maximum interval in seconds (eg. 120) that the broker should keep the connection alive, when a client maintains the MQTT connection but does not transmit any data. * **`lastWillMessage`** The lastWillMessage parameter is a message (this can be a string, e.g., 'hello' or even a JSON formatted message) a broker sends when the MQTT connection abruptly terminates without closing the connection properly. * **`lastWillTopic`** The lastWillTopic parameter states the topic (or several of them) to which the lastWillMessage should be published. In other words, all subscribers of this particular topic will get the lastWillMessage once the client goes offline. * **`lastWillQos`** The lastWillQoS parameter provides information about the Quality of Service (QoS) level to use when publishing the lastWillMessage. It can have the following values: * '0' simply forwards the message once (there is no guarantee that the message was received by the receiver) * '1' ensures the delivery of the message at least once (the message can be sent more than once) * '2' provides the delivery of the message exactly once (the message can be sent once only) * **lastWillRetain** The lastWillRetain parameter specifies whether the lastWillMessage should be retained or not. If the value is 'false' an MQTT broker publishes the lastWillMessage as a non-retained one. If the value is 'true' the lastWillMessage is published as a retained one. {% hint style="info" %} All message properties are **case-sensitive** {% endhint %} > *Tip: These parameters help you control session behavior, error handling, and device lifecycle notifications.* #### 5. Topics Topics define what data you read or write via MQTT:

Add/Edit Mqtt Topic Dialog

* Click **+ Add** to create a topic. * **Name:** Logical name for this topic (e.g., `State`). * **Payload Format:** Select `Json` (recommended). * **Topic Filter:** Specify the MQTT topic to subscribe or publish to (e.g., `acme/dallas/inctmold/p103/stamp01/status`).\ \&#xNAN;*Note: Wildcards like `+` and `#` are currently not supported.* * **Pub/Sub:** Choose **Subscribe (Read)** to collect data, or **Publish (Write)** to send data. Publishing data means that you will send Measurements from a Tag into the topic, and therefore no example payload can be added, because the format is allready predetermined by the Measurement format. * **Quality of Service (QoS):** Select the QoS level for the topic (e.g., `0` - at most once). * For **Subscribe (Read)** topics, you can preview an example JSON payload for reference. * For **Publish (Write)** topics, toggle **Retain latest published message on broker** as needed. * **Example Payload** You can optionally paste an example of a payload expected on the MQTT topic into the text area. Doing so will simplify the process of designing your Tags that utilize this Topic later on. JsonAta can be used to filter and process the payload when configuring Tags that uses MQTT Topics, and can even convert datetime values to UTC format.\ \ Below is an example of a MQTT payload in Json format: ```json { "name": "Stamper01", "state": "idle", "time": "2024-03-26T11:23:12", "errorCode": 50, "errorMessage": "servomotor position 2 disconnected" } ``` *** ### Best Practices * Use descriptive connector and topic names for clarity. * Leverage JSON payloads for rich data and easier parsing. * Secure your connection using TLS and strong credentials whenever possible. * Always test topic subscriptions/publishing with representative payloads before deploying it into a production environment. # OPC-UA ### OPC-UA Data Connector The **OPC-UA Data Connector** enables secure, real-time integration with industrial equipment and systems that support the [OPC Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/) (OPC-UA) standard. Designed to run at the Edge, this connector allows Tricloud Nexus to collect and process data from a wide variety of controllers, PLCs, KepWare Servers, and industrial devices - regardless of vendor - using a modern, secure protocol purpose-built for industrial automation. *** ### Key Features * **Edge-Based Operation:** Runs locally on Edge devices to ensure reliable, low-latency connectivity to your plant floor equipment -even if the site is offline. * **Industry Standard:** Connects to any equipment, gateway, or software supporting OPC-UA, the open protocol for industrial interoperability. * **Secure Communication:** Supports modern encryption and certificate-based security. * **Flexible Authentication:** Supports both anonymous and username/password authentication. * **Automatic Certificate Management:** Easily manage and validate security certificates for trusted communication. * **Configurable Timeouts:** Fine-tune connection, session, and request timeouts to match your network and device requirements. * **Large Message Support:** Configure maximum message sizes for efficient transfer of large data payloads. *** ### Configuring OPC-UA Data Connector **1. Add a New Connector** * Select the **Area** node where you want to connect OPC-UA equipment. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **OPC-UA**, and enter a name (e.g., `OpcUaServer`).

Add a new Data Connector

**2. Configure Connection Settings**

Configuration of OPC-UA Connector

* **Name:** Friendly name for the connector (e.g., `OpcUaServer`). * **Enabled:** Toggle to activate or deactivate this connector. * **Endpoint URL:** The full OPC-UA endpoint for your device or server (e.g., `opc.tcp://my-server.com:53530/OPCUA/MyServer`). * **Endpoint Security:** Select the desired security policy, such as `None`, `Sign (Basic256Sha256)` , or `SignAndEncrypt (Basic256Sha256)`. This defines the encryption and integrity protection for your connection. **3. Authentication** * **Authentication Method:** Choose between `Anonymous` or `Username/Password`. * **Username / Password:** If using username/password authentication, provide the required credentials. **4. Certificate Management** * **Autogenerate Application Certificate:** When enabled, the connector automatically generates and manages its own security certificate, making it easier to set up secure OPC-UA sessions. It is necessary to manually trust the certificate on the OPC-UA Server, as it is rejected by default. * **Validate Server Certificate:** Toggle to require server certificate validation for enhanced security. Only trusted servers (with valid certificates) will be connected. You must upload a server validation certificate in [PEM format](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail). **5. Advanced Settings** * **Connect Timeout:** The maximum time (in milliseconds) to wait for the initial connection to the OPC-UA server (e.g., `5000 ms`). * **Request Timeout:** Maximum time for any individual request to complete (e.g., `600000 ms`). * **Default Session Timeout:** Default time that a session remains active (e.g., `120000 ms`). * **Max Message Size:** Maximum allowed OPC-UA message size (e.g., `4194304 bytes` or `4096 MB`). #### Example OPC-UA Connector Configuration | Setting | Example Value | Description | | --------------------------- | --------------------------------------------- | -------------------------------------------- | | Name | OpcUaServer | Friendly identifier for this connector | | Endpoint URL | opc.tcp\://my-server.com:53530/OPCUA/MyServer | Address of your OPC-UA server/device | | Endpoint Security | SignAndEncrypt (Basic256Sha256) | Encrypted, signed connection | | Authentication Method | Username/Password | Secure login to the OPC-UA server | | Username | nexusclient | Your OPC-UA user | | Password | ••••••••• | (Hidden for security) | | Autogenerate Certificate | Enabled | Connector manages its own certificate | | Validate Server Certificate | Enabled | Trust only valid, signed server certificates | | Connect Timeout | 5000 ms | 5 seconds to connect | | Request Timeout | 600000 ms | 600 seconds max per request | | Session Timeout | 120000 ms | 120 seconds default session | | Max Message Size | 4194304 bytes | Up to 4 MB messages | *** ### Best Practices #### Best Practices * Always enable **encryption** (SignAndEncrypt) and use **certificate validation** for secure, trusted connections. * Use clear, descriptive connector names to simplify troubleshooting and management. * Match timeout settings to your network stability and device responsiveness - larger, slower systems may need longer timeouts. * Regularly review and manage your trusted server certificates, especially in regulated or security-sensitive environments. * Test your connector setup with representative equipment before deploying to production. # ModBus TCP ### Modbus TCP Data Connector The **Modbus TCP Data Connector** enables Tricloud Nexus to connect with industrial devices and control systems that use the Modbus TCP protocol - a widely adopted standard for communication between PLCs, sensors, meters, and other plant floor equipment. Like all data connectors in Tricloud Nexus, the Modbus TCP connector is designed to run at the Edge, providing fast, reliable data acquisition directly from your local network devices - even if the site is temporarily offline. *** ### Key Features * **Edge-Based Operation:** Runs locally on Edge devices for real-time, low-latency integration with Modbus TCP devices or servers. * **Flexible Scan & Publish Intervals:** Control how frequently data is polled from Modbus devices and published into your asset hierarchy. * **Configurable Byte & Word Order:** Ensure correct interpretation of multi-byte and multi-word values, supporting both little and big endian formats. * **Easy Integration:** Connects to standard Modbus TCP slaves - no special drivers or custom software required. * **Consistent Data Model:** All values collected are normalized into the Tricloud Nexus unified measurement format, ready for analytics, storage, or cloud integration. *** ### Configuring ModBus TCP Data Connector **1. Add a New Connector** * Select the **Area** node where you want to configure Modbus TCP integration. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **Modbus TCP**, and enter a name (e.g., `ModBusTcpServer`).

Add a new Data Connector

**2. Configure Connection Settings**

Configuration of ModBus TCP Connector

* **Name:** Friendly name for your connector (e.g., `ModBusTcpServer`). * **Enabled:** Toggle to activate or deactivate this connector. * **Slave Connection:** The IP address (or hostname) of the Modbus TCP slave device (e.g., `123.10.10.123`). **3. Configure Polling and Publishing** * **Scan Interval (ms):** How often (in milliseconds) the connector will poll the Modbus device for data. (e.g., `1000` ms = once per second) * **Publish Interval (ms):** How often (in milliseconds) collected data is published into the Tricloud Nexus system. You may use the same value as the scan interval, or set a higher/lower value to control data update rates. * **Note:** The publish interval should not be smaller than the scan interval. In most cases, set publish interval equal to the minimum scan frequency. For heavy workloads, a higher publish interval can optimize communication and performance. **4. Byte & Word Order** * **Byte Order:** Choose how bytes are ordered for multi-byte values - options are *Little* or *Big* endian. Select the setting that matches your Modbus device’s configuration. * **Word Order:** Choose how words are ordered for multi-word (e.g., 32-bit or 64-bit) values - *Big* or *Little*. This ensures correct interpretation of all data types. *** #### Example Modbus TCP Connector Configuration | Setting | Example Value | | --------------------- | --------------- | | Name | ModBusTcpServer | | Slave Connection | 123.10.10.123 | | Scan Interval (ms) | 1000 | | Publish Interval (ms) | 1000 | | Byte Order | Little | | Word Order | Big | *** ### Best Practices * **Align scan and publish intervals** to your process requirements; higher scan rates increase data resolution, but also network and processing load. * **Verify byte and word order** in your device documentation to ensure accurate data reads - incorrect settings can result in swapped or misinterpreted values. * **Use clear connector names** to simplify troubleshooting and system management. * **Test your configuration** with live equipment before moving to production. * **Buffering:** Remember, the connector will continue to collect and buffer data locally at the Edge during network outages, ensuring data continuity. # ModBus RTU ### Modbus RTU Data Connector The **Modbus RTU Data Connector** enables Tricloud Nexus to interface with industrial equipment and systems that use the Modbus RTU protocol - a global standard for serial communication with PLCs, sensors, meters, and other field devices. Running at the Edge, this connector ensures reliable data acquisition directly from RS-232/RS-485 serial networks, even during network outages or offline scenarios. **Important:** The Edge device where the Modbus RTU Data Connector is configured must be equipped with a compatible serial data connection port (such as RS-232 or RS-485). This physical connectivity is required for direct communication with Modbus RTU devices at the Edge. ### Key Features * **Edge-Based Operation:** Runs locally on Edge devices for real-time integration with Modbus RTU devices, ensuring data collection continues even if your site is offline. * **Serial Connectivity:** Connects directly to Modbus RTU slave devices via serial ports (RS-232/RS-485). * **Flexible Polling & Publishing:** Independently configure scan and publish intervals for optimal data throughput and efficiency. * **Full Protocol Control:** Adjust baud rate, data bits, stop bits, and parity to match your device and network requirements. * **Configurable Byte & Word Order:** Supports both little and big endian formats to ensure proper interpretation of complex values. * **Unified Data Model:** All collected values are normalized into the Tricloud Nexus measurement format, ready for analytics, storage, and integration with cloud or enterprise systems. ### Configuring ModBus RTU Data Connector #### 1. Add a New Connector * Select the **Area** node where you want to configure Modbus RTU integration. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **Modbus RTU**, and enter a name (e.g., `ModBusRtuServer`).

Add a new Data Connector

#### 2. Configure Connection Settings

Configuration of ModBus RTU Connector

* **Name:** Friendly name for your connector (e.g., `ModBusRtuServer`). * **Enabled:** Toggle to activate or deactivate this connector. * **Slave Connection:** The serial port or IP/host for the Modbus RTU slave device (e.g., `123.10.10.123`). (Note: Serial port configuration may depend on your Edge hardware.) #### 3. Configure Polling and Publishing * **Scan Interval (ms):** How often (in milliseconds) the connector will poll the Modbus device for data (e.g., `1000` ms = once per second). * **Publish Interval (ms):** How often (in milliseconds) collected data is published into Tricloud Nexus. Set this to match or exceed the scan interval to avoid data loss. * **Note:** The publish interval should not be smaller than the scan interval. In most cases, set publish interval equal to the minimum scan frequency. For heavy workloads, a higher publish interval can optimize communication and performance. #### 4. Serial Communication Settings * **Baud Rate:** Set the communication speed in bits per second (e.g., `9600, 14400, 19200`). Must match the setting on your Modbus RTU device/network. * **Data Bits:** Number of data bits per character (e.g., `7` or `8`). * **Stop Bits:** Number of stop bits per character (e.g., `1, 1½` or `2`). * **Parity:** Parity setting for error checking (e.g., `Even`, `Odd`, or `None`). #### 5. Byte & Word Order * **Byte Order:** Set the byte ordering for multi-byte values (*Little* or *Big* endian). * **Word Order:** Set the word ordering for multi-word values (*Little* or *Big*). *** **Example Modbus RTU Connector Configuration** | Setting | Example Value | | --------------------- | --------------- | | Name | ModBusRtuServer | | Slave Connection | 123.10.10.123 | | Scan Interval (ms) | 1000 | | Publish Interval (ms) | 1000 | | Byte Order | Little | | Word Order | Little | | Baud Rate | 9600 | | Data Bits | 7 | | Stop Bits | 1 | | Parity | Even | *** ### Best Practices * **Match Serial Settings:** Ensure baud rate, parity, data bits, and stop bits match those of your Modbus RTU device and network. Incorrect settings will prevent communication. * **Align Intervals:** Align scan and publish intervals to your operational needs - higher scan rates yield more detailed data but increase device and network load. * **Validate Byte & Word Order:** Check your device documentation to select the correct byte and word order. Incorrect settings may produce swapped or inaccurate values. * **Test with Live Devices:** Always test your connector with real hardware before deploying to production. * **Buffering:** The connector will buffer data at the Edge during network outages, ensuring data is not lost and is sent to the cloud once connectivity is restored. * **Use Descriptive Names:** Clear connector names help with management and troubleshooting. # Historian ### Historian Data Connector The **Historian Data Connector** allows Tricloud Nexus to store time-series measurements from your Edge-connected devices directly into a dedicated database for long-term archiving, advanced analytics, and reporting. This connector acts as a **data sink -** meaning it receives measurement data from other [data connectors](/management-portal/designer/assets/data-connectors) (such as MQTT, OPC-UA, Modbus, etc.) and writes those measurements into the historian database of your choice. The Database can be physically located at a local site or in the cloud. > **Note:**\ > Currently, only **TimeScaleDB** (based on PostgreSQL) is supported as a historian target, but additional options such as Microsoft SQL Server will be added in future releases. *** ### Key Features * **Flexible Historian Support:** Store measurements in industry-standard databases, starting with TimeScaleDB. * **Edge-Based Storage:** Data can be buffered and written from Edge devices, supporting robust operation even if connections are intermittent. * **Batched Writes:** Optimize performance and reduce network traffic by batching multiple measurements before writing to the database. * **Secure Access:** Authentication required for database connections, with full support for credentials management. * **Configurable Storage:** Set maximum storage intervals and batch sizes to match your data retention and performance requirements. * **Unified Data Model:** All measurements stored follow the Tricloud Nexus measurement format, ensuring consistency and easy integration for analytics. *** ### Use Cases for Historian Data Connector The Historian Data Connector is especially useful in scenarios where you need to store selected, high-value operational data from your Edge environment for advanced analytics, compliance, or reporting. Some common use cases include: * **OEE (Overall Equipment Effectiveness) Tracking**\ Store a targeted subset of measurements - such as cycle counts, downtime events, quality rejects, and production rates - from specific tags. This enables efficient calculation and historical analysis of OEE metrics directly in your preferred database. * **Long-Term Data Retention for Compliance**\ Retain process-critical data or regulatory measurements in a secure, queryable SQL database (such as TimeScaleDB or, in future, SQL Server) to meet compliance requirements for traceability and audit trails. * **Custom Reporting & Business Intelligence**\ Feed measurement data into BI tools or custom dashboards by writing measurements to a historian that’s accessible to your enterprise reporting infrastructure. * **Cross-System Integration**\ Make selected operational data available to IT or business systems, ERP, or MES by writing measurements from Edge into a centralized, SQL-based historian. * **Data Archiving**\ Archive a subset of key measurements from Edge devices and connectors for backup, disaster recovery, or later review - without sending all raw field data to the cloud. * **Selective Data Storage**\ Optimize your storage and network usage by only persisting tags and measurements that are most relevant for your business KPIs, instead of archiving every data point collected at the Edge. These use cases make the Historian Data Connector a powerful tool for bridging your IIoT data model with the broader IT landscape - supporting both operational needs and strategic decision making. *** ### Configuring the Historian Data Connector #### 1. Add a New Connector * Select the **Area** node where you want to configure Modbus RTU integration. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **Historian**, and enter a name (e.g., `Historian`).

Add a new Data Connector

#### 2. Configure Connection Settings

Configuration of Historian Connector

* **Name:** Friendly name for your connector (e.g., `Historian`). * **Enabled:** Toggle to activate or deactivate this connector. * **Historian Type:** Select `TimeScale DB` (support for additional databases will be available in the future). * **Database Name:** Name of your target database (e.g., `mydatabase`). * **Historian Address:** Hostname or IP address of your database server (e.g., `123.10.10.153`). * **Historian Port:** Port number for the database connection (default for TimeScaleDB/Postgres is `5432`). #### 3. Authentication * **Username:** Database username (e.g., `nexusclient`). * **Password:** Password for the database user. #### 4. Batched Storage There are two ingestion modes available: * **Batched (recommended for most scenarios)**\ Batching measurements is a way to reduce load on the historian module, but has the disadvantage that it introduces a delay before measurements are available on the historian. Measurements are buffered and written in batches using: * **Maximum storage interval:** Maximum time to buffer measurements before writing them in a batch (e.g., 1 minute). * **Maximum batch size:** Maximum number of measurements per batch (e.g., 500). Set to optimize between latency and performance. * **Immediate (per-sample writes)**\ Store each measurement as soon as it’s produced. This minimizes latency but increases write IOPS and CPU usage. {% hint style="info" %} **Performance guidance:** Start with **batched** ingestion and tune the interval/size to your device and workload. Use **immediate** writes only for critical, low-latency signals and monitor system load (CPU, disk I/O) to avoid contention. {% endhint %} *** #### Example Historian Connector Configuration | Setting | Example Value | | ------------------------ | ------------- | | Historian Type | TimeScale DB | | Database Name | mydatabase | | Historian Address | 123.10.10.153 | | Historian Port | 5432 | | Username | nexusclient | | Password | •••••••••• | | Measurement Batching | Enabled | | Maximum Storage Interval | 1 minute | | Max Batch Size | 500 | *** ### Best Practices * **Use batching** to optimize storage performance and minimize network traffic, especially for high-frequency data streams. * **Choose meaningful connector names** to simplify troubleshooting and system management. * **Secure your database** by using strong credentials and network security best practices. * **Monitor storage intervals and batch sizes** to ensure you meet your latency and data retention requirements. * **Plan for growth:** As support for more historian types becomes available, review your architecture for best-fit options. # FTP Server ### FTP Server Data Connector The FTP Server Data Connector enables Tricloud Nexus to transfer files between your Edge devices and external servers using the standard FTP, FTPS, or SFTP protocols. This connector is designed for robust, secure integration with legacy equipment, industrial file servers, lab systems, or cloud storage endpoints, supporting both data collection and automated job workflows at the Edge. > **Note:**\ > The FTP Server Data Connector can be used for both file uploads (send files from Edge to a server) and downloads (retrieve files from a server), depending on how you configure [Jobs](/management-portal/designer/assets/jobs) on the Area. *** ### Key Features * **Multi-Protocol Support:** Connect using plain FTP, secure FTPS (FTP over TLS), or SFTP (SSH File Transfer Protocol) for maximum compatibility. * **Edge-Based Operation:** Runs on Edge devices, enabling local file transfer workflows even when disconnected from the cloud. * **Secure File Transfer:** Supports TLS/SSL encryption (for FTPS), SSH-based encryption (for SFTP), certificate validation, and explicit or implicit security modes. * **Timezone Handling:** Automatically manage file timestamps with configurable server timezone settings for consistent archiving and traceability. * **Flexible Integration:** Works with most file-based lab equipment, data recorders, and enterprise file servers. *** ### Configuring the FTP Server Data Connector **1. Add a New Connector** * Select the Area node where you want to configure file transfer integration. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **FTP Server**, and enter a name (e.g., `FtpServer`).

Add a new Data Connector

#### 2. Configure Connection Settings

Configuration of FTP Server Connector

* **Name:** Enter a descriptive name for your connector (e.g., `FtpServer`). * **Server Address:** Specify the IP address or DNS hostname of the FTP/FTPS/SFTP server (e.g., `123.10.10.156`). * **Server Port:** Set the port number for the server. Default is `21` for FTP/FTPS and `22` for SFTP. * **Protocol:** Choose `FTP/FTPS` or `SFTP` depending on your server and security requirements. #### 3. Authentication & Security * **Username:** Enter the username for FTP/SFTP authentication. * **Password:** Enter the password for the account. * **TLS Enabled:** Toggle ON to enable TLS encryption for FTPS (ignored for SFTP and plain FTP). * **TLS Protocol:** Select the TLS version (e.g., `TLS 1.2`) for secure FTP connections.\ \&#xNAN;***Protocol Tips:*** * *Use **FTPS** or **SFTP** for secure, encrypted transfers whenever possible.* * *Match the protocol, port, and encryption settings to your server’s configuration.* * **Encryption Mode:** Set the Encryption mode to either `None` , `Explicit` or `Implicit`. The type of Encryption Mode determines how the connection is initiated, when the Edge device connects to the FTP Server. * **None** Use plaintext FTP (Not recommended) * **Explicit** TLS connects in FTP on port 21 and upgrades to FTPS over another port (50000-51000), throws an exception if encryption is not supported. (**Recommended**) * **Implicit** SSL directly connects in FTPS assuming the control connection is encrypted. This has to be supported by the FTP server and usually uses port 990. *Default encryption mode is Explicit.* * **Validation Certificate:** (Optional, recommended) Upload a certificate file to validate the server for FTPS/SFTP connections. The validation certificate should be the public client certificate that the FTP server uses to encrypt the traffic. If no validation certificate is added, the Edge device will accept any SSL certificate received from the server and skip performing the validation. The certificate should be added in **CER format**. #### 4. Advanced Settings * **Server Timezone Settings:** Set the timezone of the FTP server for accurate file timestamping (e.g., `(UTC) UTC`). Most FTP Servers uses UTC Timestamps for all files, so in most cases this dropdown should be left at its default (UTC). *** ### Example FTP Server Connector Configuration | Setting | Example Value | | ------------------------ | -------------------------- | | Name | FtpServer | | Server Address | 123.10.10.156 | | Server Port | 21 | | Protocol | FTP / FTPS | | Username | nexusclient | | Password | ●●●●●●●● | | TLS Enabled | On | | TLS Protocol | TLS 1.2 | | Encryption Mode | Explicit | | Validation Certificate | \[cert file in CER Format] | | Server Timezone Settings | (UTC) UTC | *** ### Best Practices * **Always use FTPS or SFTP for sensitive or production data.** Plain FTP sends credentials and data unencrypted. * **Match encryption mode (Explicit/Implicit) and port to your server’s configuration.** * **Validate server certificates** whenever possible to prevent man-in-the-middle attacks. * **Set the correct timezone** for your server to avoid confusion with file timestamps and job scheduling. * **Choose clear connector names** for easy troubleshooting and management. # File Share ### File Share Server Data Connector The File Share Server Data Connector enables Tricloud Nexus to integrate with traditional network file shares using the Samba Protocol (SMB), allowing Edge devices to read from or write to shared folders on Windows servers, NAS devices, or other compatible systems. This connector is ideal for automating file exchange with legacy applications, lab equipment, document archives, or enterprise IT systems - bridging OT and IT workflows securely at the Edge. > **Note:**\ > This connector is commonly used for file-based integration [jobs](/management-portal/designer/assets/jobs) such as uploading production reports, retrieving recipe files, or exchanging batch documentation between the factory floor and central servers. *** ### Key Features * **Edge-Based Operation:** Connects Edge devices directly to local or remote SMB/CIFS file shares, even if cloud connectivity is unavailable. * **Flexible Compatibility:** Supports modern SMB protocol versions (e.g., SMB 2.0) and a variety of authentication methods. * **Domain Support:** Can join Active Directory or workgroup-based shares as needed for enterprise security. * **Direct Transport:** Uses direct TCP/IP for efficient, secure file transfer. *** ### Configuring the File Share Server Data Connector **1. Add a New Connector** * Select the **Area** node where you want to configure file share integration. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **File Share Server**, and enter a name (e.g., `FileShareServer`).

Add a new Data Connector

**2. Configure Connection Settings**

Configuration of FileShare Connector

* **Name:** Enter a descriptive name for your connector (e.g., `FileShareServer`). * **Server Address:** IP address or DNS hostname of the file server (e.g., `123.10.10.156`). * **File Share Name:** The name of the shared folder (e.g., `SharedDocuments`). You must enter a name as it appears on the network. Share names are generally **case-insensitive**. This is particularly true on Windows-based SMB servers. * **Domain:** (Optional) Enter a valid domain (e.g., `company.local`) if required for authentication, otherwise leave blank for workgroup access. If you are connecting to a standalone server that is not part of a domain (it's in a workgroup), you typically do not need to specify the domain. In such cases, you would authenticate using local user accounts defined on the SMB server itself. * **Non domain joined file share server (Workgroup)** - Leave the domain input blank. Instead use the credentials of a locally created user account on the file share server to connect. * **Domain joined server (Active Directory Domain Environment)** - You must specify the name of the domain so the credentials used to connect can be verified by the AD domain. Example of domain: mycompany.com **3. Authentication** * **Username / Password:** Credentials for accessing the file share (e.g., `nexusclient`). * **Protocol:** Select the SMB protocol version (e.g., `SMB 2.0`). Match this to your server’s configuration for best compatibility and security: * **SMB 1.0** - Older protocol supported by the following operating systems:\ Windows XP\ Windows Server 2003 * **SMB 2.0** - Newver protocol supported by the following operating systems:\ Windows 7\ Windows 8\ Windows 10\ Windows 11\ Windows Server 2008\ Windows Server 2008R2\ Windows Server 2012\ Windows Server 2016\ Windows Server 2019\ Windows Server 2022 * **Transport Type:** Choose `Direct TCP IP` for most modern environments. *** ### Example File Share Data Connector Configuration | Setting | Example Value | | --------------- | -------------------------------------------- | | Name | FileShareServer | | Server Address | 123.10.10.156 | | File Share Name | SharedDocuments | | Domain | (leave blank for workgroup) or mycompany.com | | Username | nexusclient | | Password | ●●●●●●●● | | Protocol | SMB 2.0 | | Transport Type | Direct TCP IP | *** ### Best Practices * Use **strong credentials** and keep them updated for secure access. * Match **protocol version** (e.g., SMB 2.0) to your server’s configuration - older servers may require SMB 1.0 (not recommended due to security risks). * Specify the correct **domain** if your environment uses Active Directory; otherwise, use local or workgroup accounts. * Use **clear connector names** to simplify troubleshooting and management. * Validate access and file permissions with a test job before deploying in production. # Camera (Scene Controller) ### Camera (Scene Controller) Data Connector The Camera (Scene Controller) Data Connector allows Tricloud Nexus to interface with industrial cameras and their associated lighting controllers directly from the Edge. This enables real-time image acquisition, process monitoring, and integration of vision systems with your IIoT data model - ideal for quality control, visual inspection, and automation workflows. This connector can be configured to acquire images via a REST API endpoint, with customizable camera and image settings, as well as optional integration with an external lighting controller for scene management. *** ### Key Features * **Edge-Based Operation:** Runs locally on Edge devices for low-latency, high-throughput image acquisition—even when the site is offline. * **RESTful Camera Integration:** Connect to industrial cameras supporting REST API for image capture. * **Customizable Image Settings:** Specify image resolution (height & width), format (BMP, JPEG, PNG, etc.), and pixel format (e.g., Mono8, RGB). * **Integrated Scene Lighting:** Optionally control an external lighting controller to ensure optimal image quality and repeatability. * **Multi-Channel Support:** Configure multiple lighting channels for complex inspection scenes. * **Consistent Data Model:** Image metadata and results are integrated into the Tricloud Nexus data platform for seamless downstream analytics. *** ### Configuring the Camera (Scene Controller) Data Connector **1. Add a New Connector** * Select the **Area** node where you want to configure camera integration. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **Camera**, and enter a name (e.g., `Camera`).

Add a new Data Connector

**2. Configure Connection Settings**

Configuration of Camera and Scene Controller Connector

* **Name:** Enter a descriptive name (e.g., `Camera`). * **Camera API URL:** The REST API endpoint for image acquisition (e.g., `http://172.0.0.1:34568/image/acquire`). **3. Camera Settings** * **Image Height:** Set the height (in pixels) for the captured image (e.g., `2048`). * **Image Width:** Set the width (in pixels) for the captured image (e.g., `2592`). * **Image Format:** Choose the file format for acquired images (e.g., Bitmap (BMP), JPEG, PNG). * **Pixel Format:** Select the pixel encoding (e.g., Mono8 for grayscale, RGB for color). **4. Lighting Controller (Optional)** * **Lighting Controller Enabled:** Toggle ON to enable external lighting control. * **Lighting Controller IP:** Enter the IP address of the lighting controller (e.g., `172.0.0.2`). * **Lighting Controller Port:** Specify the port for the lighting controller (e.g., `40001`). * **Lighting Controller Channels:** Set the number of available lighting channels (e.g., `4`). *** ### Example Camera (Scene Controller) Data Connector Configuration | Setting | Example Value | | ---------------------------- | -------------------------------------- | | Name | Camera | | Camera API URL | | | Image Height | 2048 | | Image Width | 2592 | | Image Format | Bitmap (BMP) | | Pixel Format | Mono8 | | Lighting Controller Enabled | Yes | | Lighting Controller IP | 172.0.0.2 | | Lighting Controller Port | 40001 | | Lighting Controller Channels | 4 | *** ### Best Practices * Use clear and descriptive connector names, especially if multiple cameras or lighting controllers are used. * Match image settings (resolution, format, pixel type) to your application’s needs for processing and storage efficiency. * Enable the lighting controller for repeatable, high-quality imaging—particularly in automated inspection tasks. * Validate the Camera API endpoint and lighting controller connectivity with test captures before deploying in production. * Secure the API endpoints and device networks to prevent unauthorized access. *** ### Typical Use Cases * Automated visual quality inspection in manufacturing. * Integration with AI/ML models for real-time vision analytics. * Barcode or QR code reading and traceability. * Process monitoring and product documentation. # Emulator ### Emulator Data Connector The Emulator Data Connector enables rapid prototyping and testing of Tricloud Nexus asset hierarchies, tags, and integrations without the need for real-world equipment or external data sources. This connector is designed to generate simulated measurement data at the Edge, providing a safe and controlled environment for validating system configuration, analytics, dashboards, and jobs before connecting to live systems. > **Note:**\ > The Emulator Data Connector is intended for development, demonstration, and test scenarios. It should not be used in production environments. *** ### Key Features * **Edge-Based Simulation:** Runs directly on your Edge device, generating synthetic measurement values for any configured Tag. * **Safe Testing:** Allows for end-to-end workflow validation - test dashboards, jobs, analytics, and historian connectors without risking real production data. * **Rapid Prototyping:** Quickly simulate tag value changes, error states, or process scenarios before your physical equipment is connected. * **Flexible Activation:** Enable or disable emulation data simply by toggling a button. * **No External Dependencies:** Does not require any protocol setup, network configuration, or external connections. *** ### Configuring the Emulator Data Connector 1. **Add a New Connector** * Select the Area node where you want to simulate equipment or tags. * Go to the **Data connectors** tab. * Click **+ New data connector**, choose **Emulation**, and enter a name (e.g., `Emulator`). 2. **Enable/Disable Simulation**

The only option is toggling whether the Emulator Connector is Enabled

* Use the **Enabled** toggle to activate or deactivate the emulator. 3. **Connect Tags** * Any tags assigned to this connector can receive simulated measurement values according to their type (analog, digital, string). In the Tag configuration of a Tag, set the Data Connection to the Emulator, then specify how measurements should be generated using one of the below configurations/strings in the Read Address field: * *Sine curve:* Generate data that follows a sine curve, you may use the following example.\ This will generate data from 0 to 10 over a period of 30 seconds.\ Example: **sinus;0;10;30** * *Step:* Generate stepwise data within a range.\ Alternate between two numbers for set durations before reverting to the original number.\ Example: **step;-10;5;10;15** * *Sequence:* Generate a predetermined series of data repeatedly.\ The following example produce a series of data that corresponds with the numbers.\ Example: **sequence;1;2;3;4;5** (output: 1, 2, 3, 4, 5) * *Random:* Generate a series of random numbers from within a range.\ Example: **random;1000** (range from 0 to 1000)\ Example: **random;100;200** (range from 100 to 200) * *Variance:* Adding the variance tag to any formula will produce noise on every individual output.\ The final output is the product of the variance and the original value. It is most useful for "roughing up" sine curves.\ Example: **sinus\[variance=0.3];0;10;30**\ \\

Simulated Tag that uses the Emulator Data Connector

*** ### Example Emulator Connector Configuration | Setting | Example Value | | ------- | ------------- | | Name | Emulator | | Enabled | On | *** ### Best Practices * Use the Emulator Data Connector to build and validate new asset hierarchies or dashboards before deployment. * Simulate process variations and alarm scenarios to test job automation, notification logic, or data flows. * Clearly name your emulator connector and tags to avoid confusion between simulated and live data. --- [Next Page](/llms-full.txt/1)