This article outlines the information required to evaluate and design a new driver (data connector) for integration with the IOTA platform. Whether you're a customer requesting support for a new data source, a partner assisting with integration, or an internal team member preparing for customer support and development - use this checklist to gather all relevant technical and operational requirements.

0. System Identification

Please collect the following basic information about the source system:

• Source System / Vendor Name
  e.g., AVEVA PI System, Siemens PCS7, Ignition, etc.

• System Version / Build
  Include API version, server version, or relevant plugin/module versions if applicable.

1. Use Cases & Visualization Goals

Help us understand the value the user expects from the integration. This ensures the driver supports relevant business outcomes.

• What types of users will interact with the data?
  e.g., operators, engineers, analysts, managers

• What are the primary use cases for visualization?
  e.g., ad hoc analysis, KPI monitoring, exception-based event response, performance benchmarking

• Are there specific displays or dashboards that need to be built?
  e.g., trend charts, status overviews, batch performance, asset comparisons

• Is data primarily for live monitoring, historical analysis, or both?

• Is drill-down into assets or time windows required?

• Are users expecting mobile, tablet or video wall experiences?

• What decisions or actions should the user be able to take using this data?

 
2. Data Structure and Interaction

A. Types of Data

Which types of data are available for integration?
☐ Time series / Tags
☐ Asset hierarchy or structure with asset attributed and metadata
☐ Timeframes (batches/ events / alarms)

☐ Data Sets (data that can be represented as a table, similar to views and tables in relational databases)
☐ Other data types

B. Write-Back or Workflows

• Is there a need to send data back to the system (e.g., change of inputs, write back new tag values)?

• Do you need to trigger workflows or execute server-side functions via API calls?

C. Example Structures

Please provide:

• Sample tag names and value pairs

• A typical asset with its attributes

• Example API response or JSON payload (if available)

3. Data Access & API Overview

A. Available Interfaces

• What APIs or interfaces are available? Examples include:
  ☐ REST API (HTTP/HTTPS)
  ☐ Proprietary SDK or API
  ☐ OPC UA / DA
  ☐ Direct DB Access (SQL, NoSQL)

• Is the API publicly documented?
  ☐ Yes → Please provide link
  ☐ No → Please share a spec or sample payload

B. Deployment Model

• Where does the data reside?
  ☐ On-premises
  ☐ Cloud-hosted
  ☐ Hybrid

• Requirements for driver deployment:
  ☐ Must run on the same network as the data source
  ☐ Requires specific OS, VM, or can be container-deployed as part of IOTA cluster (depending on the integration interface used)
  
  

• Will single IOTA driver (aka same client application) require support for multiple instances of this data source (e.g., multiple plants, databases, or environments)?

 
4. Data Updates and Query Efficiency

A. Data Granularity and update behavior

• How frequently is data sampled or updated on the data source - what are the typical, as well as extreme cases (highest and lowest frequencies)?

• How frequently visualization is expected to update? e.g., near-real time, every 5 seconds, every minute, event-based only, on demand/scheduled updates

• Is historical data available?
  ☐ Yes → How far back?
  ☐ No → Only real-time/live data (snapshot updates)

B. Display-Aware Historical Queries

• Does the system support resolution-aware historical queries?

In many use cases, users view trends or time series on-screen, and it’s not necessary to return every raw data point to render an accurate visualization. For example, displaying a week’s worth of data across 100 pixels doesn’t require hundreds of thousands of records—it requires representative points that preserve spikes, dips, and direction of change.

A display-aware query (in some systems referred to as Plotted Value calls) adapts to the client's screen resolution by returning points that are already pre-aggregated using the following considerations:

• Min/Max values for each pixel-width interval (to preserve spikes)

• Previous value (to draw directional lines correctly)

This greatly reduces data volume while maintaining visual accuracy, improving both performance and user experience.

C. Bulk Query Optimization

• • Are bulk data queries supported for multiple items (tags/assets)?
    e.g., fetch many tags in a single request

  • Are bulk queries supported for historical data?
    e.g., retrieve historical values for multiple tags over the same time range in one request

  • Are bulk queries supported for near-real-time data?
    e.g., fetch the latest value for many tags at once

  • Is the data source self-discoverable?
    e.g., can the driver query available tags, assets, or data structures dynamically

5. Authentication & Security

A. Supported Authentication Methods

What is preferred method of authentication? For example:

☐ Basic Auth (username/password)
☐ API Key / Token
☐ OAuth 2.0 (Client ID/Secret)
☐ Certificate-based (mTLS)
☐ SAML / SSO
☐ Windows Integrated Auth (Kerberos, AD)

☐ Other

B. Access Permissions

• Are there role-based access levels (e.g., read/write)?

• Do users need specific scopes or roles to access certain data?

C. Security Policies (Uncommon)

• Rate limits or throttling?

• IP restrictions or geo-blocking?

• Required headers, signed tokens, or other constraints?

• Are there additional firewall, proxy, or VPN requirements for access?

• Is direct network access or IP whitelisting required?

6. Implementation and Development Considerations

A. Development Environment

• Are test/sandbox environments available and can be provided for IOTA team?

B. Licensing

• Is access to the API or system gated by licensing or commercial terms?

C. Technical/Partner Contact

Please provide a main point of contact for technical discussions:

• Full Name

• Role / Title

• Email Address

• Preferred Communication Channel (e.g., Email, Teams)