Key Concepts

Fleetera is built around a set of interconnected concepts. Understanding how they relate to each other will help you get the most out of the platform.

Sites

A site is the top-level entity representing a physical location — a power plant, a manufacturing facility, a data center, or any other industrial installation. Sites are the root of your asset hierarchy.

Each site has:

• A category — chosen from 12 platform-provided categories organized into industry groups (Energy, Manufacturing, Infrastructure, Buildings, General), or a custom category you define
• A location — GPS coordinates and a human-readable label
• An operational status — Active, Inactive, or Under Maintenance
• A commissioned date — when the site became operational

Assets

An asset is a digital representation of a physical piece of equipment. Assets are organized in a hierarchy under a site, forming a digital twin of your physical infrastructure.

For example, a manufacturing facility might contain:

Automotive Plant (Site)
├── Production Line A
│   ├── CNC Machine 001
│   ├── Robotic Welder 001
│   └── Conveyor System
├── Production Line B
│   ├── CNC Machine 002
│   └── ...
└── Utility Room
    └── Compressor

Assets can be nested to any depth. Each asset belongs to a category (e.g., "CNC Machine", "Generator", "Pump") that classifies what type of equipment it represents.

Asset templates

An asset template is a reusable blueprint for creating assets. Instead of manually creating each piece of equipment and its subsystems one by one, you define a template once and instantiate it as many times as needed.

Templates support:

• Hierarchy — a template can include child templates (e.g., a machine template with motor, drive, and sensor sub-templates)
• Variable definitions — measurement data points pre-defined on the template
• Versioning — every change to a template creates a new version with a changelog
• Bulk instantiation — create dozens of identical asset hierarchies in one operation

Variables

A variable represents a measurement data point on an asset — a value that can be read from physical equipment. Examples include temperature (°C), pressure (bar), flow rate (m³/h), power consumption (kW), or vibration (mm/s).

Variables have:

• A key — a unique machine-readable identifier in snake_case format (e.g., temperature, flow_rate)
• A name — a human-readable label (e.g., "Temperature", "Flow Rate")
• A data type — Float64, Int32, Boolean, String, etc.
• A unit code — kW, m/s, rpm, °C, %, etc.
• A kind — raw (read from a device), derived (computed, no connector), or kpi (the output of a KPI definition)

Variable libraries

Variable libraries are curated collections of variables grouped by industry standard or asset type. The platform provides built-in libraries for common industrial equipment, and you can create your own tenant libraries. Libraries make it easy to standardize variable naming and units across your organization.

Connectors

A connector represents a connection to an industrial data source — the bridge between your physical equipment and the Fleetera platform. Each connector is configured with a specific communication protocol and endpoint.

Supported protocols:

• OPC UA — opc.tcp://host:port/path
• Modbus TCP — host, port, slave ID
• CAN bus — interface, baud rate
• REST API — base URL, authentication
• Custom — extensible for proprietary protocols

Connectors are attached to assets. Child assets inherit their parent's connector unless they have their own connector assigned.

Each connector tracks its health status: Healthy, Degraded, Offline, or Unknown.

Variable bindings

A variable binding links a variable on an asset to a specific data point in a connector. It tells the system: "to get the value of this variable, read this address from this connector."

For example, binding the active_power variable to OPC UA node ns=2;s=ActivePower on a connector means the edge gateway will poll that OPC UA node and stream the value to the platform as the asset's active power.

Bindings support data transformation:

• Scale — multiply the raw value (e.g., convert W to kW)
• Offset — add a constant to the value
• Deadband — suppress updates when the change is smaller than a threshold
• Sampling interval — how often to poll the data point (in milliseconds)

Fleetera offers AI-powered match suggestions that automatically propose bindings between your variables and data points in a connector's data model, dramatically reducing manual configuration effort.

Edge deployments

An edge deployment is a virtual configuration of a gateway that runs at a customer site on a Linux server. The edge gateway:

• Connects to local industrial data sources via connectors
• Acquires telemetry data at configured intervals
• Streams data to the Fleetera cloud platform
• Receives configuration updates from the cloud

A site can have one or multiple edge deployments. Each deployment targets a specific hardware architecture (amd64 or arm64) and is installed by running a bootstrap command on the target machine.

Deployment statuses: Pending → Deploying → Online / Offline / Error

Device shadow

The device shadow tracks the desired and actual state of an edge deployment's configuration. It follows a pattern similar to AWS IoT Device Shadow:

• Desired state — the configuration the cloud wants the edge to have (edge device profiles and devices)
• Reported state — the configuration the edge currently has applied
• Delta — whether there are unapplied changes
• Sync status — in_sync, pending, applying, or error

When you publish a configuration, the desired state is updated. The edge agent polls for changes, downloads the new configuration, applies it, and reports the result. This ensures reliable configuration delivery even when connectivity is intermittent.

How everything connects

Site
  └── Assets (hierarchical digital twin)
        └── Variables (measurement data points)
              └── Bindings (link to connector addresses)
                    └── Connectors (protocol bridges)

Edge Deployment (gateway at site)
  └── Device Shadow (desired vs. reported config)
        └── Edge Config (profiles + devices, generated from bindings)

Template (reusable blueprint)
  └── Variable Definitions (pre-defined data points)
  └── Child Templates (hierarchy blueprint)

Next steps