Overview

This section explains cross-functional relationships and background on niotix, in particular the data model and typical steps in the UI.

Data model

The diagram below summarizes the main objects and their relationships (cardinalities). In practice: an Account is the tenant boundary. Digital Twins, Virtual Devices, Device Templates, and Smart Groups are created and managed within it. Connectors take in data from outside or deliver it to target systems. Each Integrationflow filters and transforms events and forwards them; it is created under Integrations in Integrationflows. Users and API Keys are the two identity paths: people sign in interactively; API Keys authenticate programmatic access (scripts, interfaces). In both cases, Permissions, Roles, and Scopes control what is allowed.

User

• Meaning: Sign-in and identity in niotix. Everything visible or editable in the UI depends on the rights assigned to the user.
• Typical use: A user can belong to several Accounts (e.g. a corporate group with sub-accounts) and switch context by task without using separate systems.
• Relationships: Permissions define which actions are allowed; Scopes limit the “surface” in the system. For programmatic access without an interactive login, see API Keys.

API Keys

• Meaning: Access to niotix without interactive sign-in—for automation, interfaces, or embedded views. Like Users, Permissions, Roles, and Scopes define what is allowed.
• Typical use: Under Accounts, API Keys tab: create, label, rotate or revoke as needed; choose Roles and rights so only the required capability is granted.
• Relationships: Belongs to exactly one Account; in the diagram, the same path as Users through Permission, Scope, and Role.

Permission

• Meaning: Technical mapping of allowed actions (e.g. read, create, manage) to object types in the given context.
• Typical use: Instead of isolated one-off assignments, permissions are usually bundled in Roles and then assigned to Users or groups.
• Relationships: Each permission belongs to exactly one Scope (User) and can be linked to several Roles so the same combination of rights can be reused.

Role

• Meaning: Named set of permissions—a profile template (“read-only”, “manage Integrations”, …).
• Typical use: Maintain roles under Permissions (e.g. in the Role Editor or with the Default Role Wizard) and assign them to users instead of duplicating every permission.
• Relationships: An Account can have many roles; Users often receive Permissions indirectly via roles.

Scope

• Meaning: Boundary within which permissions apply. The diagram shows two closely related concepts:
  • Scope (User): Defines which structures from Accounts, Digital Twins, and Virtual Devices a user may access. Sub-scopes typically inherit rights from parent scopes.
  • Scope (Digital Twin): Security context for one or more Digital Twins. Virtual Devices are assigned to such a scope and inherit organization and visibility. Child Digital Twins may have their own scope or, if chosen at creation, no separate Scope and then fall under the parent twin’s scope.
• Typical use: When creating sub-accounts or deeper levels in the Digital Twin, consider who can see data—without releasing each object individually.

Account

• Meaning: Tenant or organization boundary: all Connectors, Virtual Devices, Integrationflows, and many settings are account-scoped. Accounts strictly separate data; each tenant works in its own data estate.
• Typical use: One main account for the organization; sub-accounts mainly for customers or legally separate entities, because Accounts enforce hard separation of data. Locations and projects are usually modeled inside one account via Permissions, Roles, and Scopes, rather than extra sub-accounts.
• Relationships: Hosts Connectors, Filters, Transformations, Digital Twins, Virtual Devices, Device Templates, Smart Groups, Integrationflows, Roles, API Keys, Export Schedules, and assigned Users.

Connector

• Meaning: Technical connection to the outside world—inbound data (e.g. via Connected Systems such as Firefly) or outbound delivery to a target system.
• Typical use: Create one connector per source or target, store Connection Data, and link it to Virtual Devices or Integrationflows.
• Relationships: Belongs to an Account; can be assigned to several Virtual Devices and supplies or receives data that lands in Data States or comes from Integrationflows. Details: Connectors.

Filter

• Meaning: Rules for which messages or events from an account’s data stream are passed into the respective Integrationflow.
• Typical use: Used in Integrationflows to forward data selectively—for example only events for certain Digital Twins, Connectors, or identifiers into the Integrationflow.
• Relationships: Managed by the Account and referenced from Integrationflows. Details: Filters.

Transformation

• Meaning: Changes data structure or format (e.g. generic niotix format to JSON for a web API).
• Typical use: Insert between trigger and outbound connector in an Integrationflow so the target receives the expected shape.
• Relationships: Defined account-wide and reused in Integrationflows. Details: Transformations.

Integrationflow

• Meaning: Event-driven forwarding: a Trigger (e.g. raw data after the connector, changed Data States, entries in Alarm Logs) starts an Integrationflow—with Filters, Transformations, and at least one outbound Connector in a fixed order.
• Typical use: Send data selectively to external systems—e.g. monitoring, a ticketing system, a database, or a partner interface. Filters and Transformations define what information is sent in what format via the Connector. What niotix produces from Rules and Data States on the Digital Twin or Virtual Device remains the business source there; the Integrationflow only transports and adapts it for the target.
• Relationships: Belongs to an Account; uses Filters, Transformations, and Connectors as steps. Full explanation including triggers: Integrationflows.

Digital Twin

• Meaning: Semantic model for assets, sites, or structures—not only a single device, but often a hierarchy (building → floor → plant).
• Typical use: In the UI under Digital Twins, data is contextualized—e.g. via location or grid references such as GIS ID or MeLo—and enriched with master data. The Digital Twin is an abstraction layer above a single Virtual Device: measurement and state information is semantically placed here, not only device-centric. It is the central integration layer outward: connections to third-party applications such as a low-voltage control system, an ERP system, or comparable operational systems. Permissions via Scopes and Dashboards typically refer to this structured view.
• Relationships: May have child Digital Twins; has Rules and Data States; Virtual Devices are assigned to a Digital Twin.

Virtual Device

• Meaning: Representation of a concrete endpoint in the platform: connection to the Connector, Packet Parser and status logic in the Device Driver, and assignment to the Digital Twin come together here.
• Typical use: Create in Device Management or import via CSV Import, choose Device Driver or Device Template, maintain tags and groups; then use Data States and Alarm Logs.
• Relationships: Belongs to a Scope (Digital Twin); references exactly one Device Driver and may reference a Device Template; has its own Rules and Data States; Dynamical Data Routing can map Virtual Device Data States to Digital Twin Data States (e.g. for higher-level KPIs). Smart Groups aggregate devices dynamically by criteria.

Device Driver

• Meaning: Reusable definition of how raw data (e.g. hex) is turned into structured values with Single Parser, Multi Parser, or Function Parser, and how Device status config evaluates state.
• Typical use: Maintain once centrally in Device Management and align many Virtual Devices of the same type; driver changes apply to all linked devices.
• Relationships: Many Virtual Devices and Device Templates can share the same Device Driver; the driver drives Packet Parser logic and health evaluation.

Device Template

• Meaning: Template for standard creation and configuration of several Virtual Devices (including Device Driver, Packet Parser, Device status config, Rules, Dynamical Data Routing).
• Typical use: Roll out series of devices of the same type without configuring each Virtual Device individually; align template changes with linked devices (sync via Device Management).
• Relationships: Belongs to an Account; references a Device Driver; Virtual Devices may reference a Device Template.

Smart Group

• Meaning: Grouping of Virtual Devices by shared attributes or filters—for analytics and overview.
• Typical use: Bundle devices by location, type, or tags without rebuilding the devices themselves; use Dashboards.
• Relationships: Belongs to an Account. There is no fixed link to individual Virtual Devices; membership is technically a filter on device attributes—the group lists Virtual Devices that match the criteria (and that set can change when data changes).

Alarm Logs

• Meaning: Log of alarms from Rules, thresholds, or states—typically in the context of Virtual Devices or Smart Groups, plus Connector monitoring.
• Typical use: View and edit entries; use as triggers for Integrationflows (see Integrationflows).
• Relationships: Each entry has an origin (e.g. Virtual Device, Smart Group, Connector). Visibility and editing are controlled by Permissions via Scopes: for device-related alarms via the Scope (Digital Twin) of the Virtual Device; for alarms related to Smart Groups or Connector context via the Account Scope.

Rules

• Meaning: Logic on a Digital Twin or Virtual Device that derives values, thresholds, or follow-up actions from incoming data or states.
• Typical use: Scaling, conversion, alarm conditions, or consolidation before storing in Data States.
• Relationships: Write to Data States of the same object; tied to Integrationflows when Data State changes act as triggers.

Data States

• Meaning: Current and historical measurement and state values assigned to a Digital Twin or Virtual Device. They are the business basis for Dashboards and Integrations; time series are persisted in the platform’s time series database.
• Typical use: Review in Data at a Glance, visualize in Dashboards, use as AFTER STATE HANDLING triggers in an Integrationflow.
• Relationships: Virtual Device Data States can map to Digital Twin Data States; Connectors and Rules feed them; Integrationflows react to changes.