IOTA connects to external systems to retrieve, process, and visualize data—without storing it. Connectivity is established through drivers, which act as translation layers between IOTA and the structure of the source system.
Each driver maps source-specific data into IOTA’s core data structures—Tags, Assets, and Timeframes—to support operations such as search, retrieving current values, accessing historical records, and write-back. Scripting is optionally available to extend built-in functionality when needed.
Data Types in IOTA
IOTA organizes source data into four standard types:
- Tags – Time-stamped values from individual data points such as sensors, control systems, or calculations.
- Assets – Logical or physical groupings of tags representing equipment, production units, or other entities.
- Timeframes – Named intervals used to filter or contextualize data (e.g., shifts, batches).
- Datasets – Tabular records such as logs or lab data, typically queried using filters and conditions.
For complete definitions and examples, see the Data Types page.
Driver Deployment Models
Drivers can be deployed either in IOTA’s backend or within the customer’s infrastructure—which may be located on-premise or in the customer's own cloud environment.
The deployment model affects where the driver runs, how it reaches the source system, and what is required during setup and maintenance.
Deployment in Customer Infrastructure
The driver is installed in an environment provisioned and operated by the customer—typically near the data source, whether on physical servers or in a private cloud.
- Required for source systems that are not accessible externally (e.g., AVEVA PI Server).
- IOTA provides the driver and supports installation and updates.
- The customer sets up the runtime environment and enables network access to the source system.
This approach offers full control but may require more infrastructure preparation and coordination on the customer side.
Deployment in the IOTA Backend
The driver runs in a containerized environment (e.g., Docker, Kubernetes) managed by IOTA as part of the IOTA backend.
- Suitable for connecting to externally accessible systems and APIs (e.g., Seeq, AVEVA Data Hub).
- No local deployment is required from the customer.
- The driver connects securely to the source system using supported authentication.
Driver Capabilities
Not all drivers support every capability. Their functionalities mainly depend on the source system and driver configuration.
Core Capabilities
- (Near) Real-time data access: Retrieves and displays data with minimal delay.
- Write-back support: Enables writing data back to the source system.
- SQL-based queries: Allows structured queries, filtering, and aggregations.
- Data transformation: Structures unstructured data into asset-based representations.
- Integration with analytics tools: Connects with platforms like Seeq for advanced analysis.
- Live visualization support: Renders real-time views from visualization applications as PI Vision.
- Calculations and advanced analytics execution: Runs Python scripts for data processing and computations.
Additional Driver Features
User Context Pass-Through:
Allows authentication using the logged-in IOTA user instead of a static service account, ensuring dynamic, role-based access control.
Example: OSIsoft AF driver supports Windows Integrated Security based on user credentials.
Ad Hoc Statistics Support:
Enables on-the-fly calculations like averages, minimum, maximum, commonly used in tables, tooltips, and trend visualizations.
Example: OSIsoft AF, OSIsoft PI, and Inmation drivers support this without requiring pre-aggregated data.
See the driver documentation for full details.
Supported Data Sources
| Data Source | Deployment | Tags | Assets | Timeframes | Write-Back | Near Real-Time Updates | Authentication |
|---|---|---|---|---|---|---|---|
| Aspen InfoPlus.21 | On-Prem | ✔️ | ✖️ | ✖️ | ✖️ | ✔️ | Explicit Login (Username/Password) |
| Aspen Inmation | On-Prem | ✔️ | ✔️ | ✖️ | ✖️ | ✔️ | Trusts, Explicit Login (Username/Password) |
| AVEVA Historian | On-Prem | ✔️ | ✖️ | ✖️ | ✔️ | ✔️ | Trusts, Explicit Login (Username/Password) |
| Azure Data Explorer (Fusion ADX) | Cloud | ✔️ | ✔️ | ✔️ | ✖️ | ✔️ | Azure AD (Service Principal) |
| Azure Synapse Analytics (SQL Pool) | Cloud & On-Prem | ✔️ | ✔️ | ✖️ | ✖️ | ✔️ | SQL Authentication, Azure AD (Username/Password), Managed Identity, Service Principal |
| Custom HTTP | Cloud | ✖️ | ✖️ | ✖️ | ✔️ | ✖️ | Bearer Token, Basic Authentication |
| CygNet | On-Prem | ✔️ | ✔️ | ✖️ | ✖️ | ✔️ | |
| Databricks | Cloud & On-Prem | ✔️ | ✔️ | ✖️ | ✔️ | ✔️ | Personal Access Token, OAuth 2.0, Client Credentials (M2M) |
| GE Proficy | On-Prem | ✔️ | ✖️ | ✖️ | ✖️ | ✔️ | Explicit Login (Username/Password) |
| Honeywell PHD | On-Prem | ✔️ | ✖️ | ✖️ | ✖️ | ✔️ | Trusts, Explicit Login (Username/Password) |
| InfluxDB | Cloud & On-Prem | ✔️ | ✔️ | ✖️ | ✖️ | ✔️ | Token-Based Authentication |
| Microsoft SharePoint | Cloud | ✔️ | ✖️ | ✖️ | ✖️ | ✖️ | Azure AD (App Certificate: Client ID, Tenant ID, Certificate, Secret) |
| MS-SQL Server | Cloud & On-Prem | ✔️ | ✔️ | ✖️ | ✔️ | ✔️ | Cloud: SQL Authentication; On-Prem: SQL Authentication, Windows Integrated Security |
| MySQL | Cloud | ✔️ | ✔️ | ✖️ | ✔️ | ✔️ | Username/Password |
| Oracle DB | Cloud & On-Prem | ✔️ | ✔️ | ✖️ | ✔️ | ✔️ | SQL Authentication |
| PI Asset Framework (AF) | On-Prem | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | PI Trusts, Explicit Login (Username/Password) |
| PI Data Archive | On-Prem | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | PI Trusts, Explicit Login (Username/Password) |
| PostgreSQL | Cloud | ✔️ | ✔️ | ✖️ | ✔️ | ✔️ | SQL Authentication, SSL Certificate |
| Python | On-Prem | ✔️ | ✖️ | ✖️ | ✖️ | ✔️ | - |
| SEEQ | Cloud | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | Username/Password |
| Snowflake | Cloud & On-Prem | ✔️ | ✔️ | ✖️ | ✔️ | ✔️ | Username/Password, Key Pair Authentication |
IOTA continuously expands its driver portfolio based on customer needs and source system capabilities. If a required driver or authentication method is missing from the list above, contact support@iotasoft.com or your Customer Success Advisor (CSA).
Driver Performance
Driver performance depends on several factors, including query complexity, network latency, source system responsiveness, and update mechanisms. The table below outlines typical patterns:
| Factor | Faster Performance | Slower Performance |
|---|---|---|
| Query Complexity and Data Structure | Simple, indexed queries retrieving small, structured datasets | Large, unindexed queries with full-table scans or complex joins/aggregations |
| Network Latency and System Responsiveness | Low-latency connections and responsive source systems | High-latency links and slow-responding servers |
| Update Mechanism | Push-based (event-driven) updates from the source system | Pull-based (polling) updates requiring repeated queries |
| Historical Data Retrieval | Optimized queries (e.g., plotted values) returning only necessary points | Full history reads without filtering or aggregation |
| Update Intervals and Refresh Settings | Longer intervals reducing load on network and systems | Short intervals increasing load and pressure |
| Suitability of Source System for Frequent Queries | Designed for high-frequency access (e.g., PI, IP.21, PHD, Proficy) | Not intended for frequent queries (e.g., Databricks, Snowflake, SharePoint) |
For help optimizing performance, contact support@iotasoft.com or your Customer Success Advisor (CSA).
Driver Security
IOTA drivers enforce security at two levels: Source System Security and IOTA API Security, ensuring controlled data access and secure communication.
Source System Security
Drivers authenticate with external data sources using varied authentication mechanisms, depending on the source system.
- User Authentication: Some drivers support Windows Integrated Security, OAuth, API tokens, or database credentials for authentication.
- Group Authorization: Certain drivers can map source system permissions to IOTA users, maintaining role-based access control. Others rely on a fixed service account with predefined permissions.
Security mechanisms vary by driver. See the driver documentation for full details.
IOTA API (Backend) Security
Drivers communicate with the IOTA Vue cluster via a secure NATS message bus. Security measures include:
- TLS Encryption: All communication is secured using TLS over port 443, ensuring data integrity and confidentiality.
- Public-Key Authentication: Uses Ed25519-based NKeys for cryptographic authentication, preventing unauthorized access.
- Challenge-Response Mechanism: Protects against replay attacks, ensuring each authentication request is unique.