Connector Concepts
Understand connector lifecycle, health status, and asset inheritance.
What is a connector
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 (such as OPC UA or Modbus TCP) and the endpoint address of the data source.
Connectors belong to a site. Once created, they are attached to assets within that site. Variables on those assets are then bound to specific data points accessible through the connector.
Supported protocols
| Protocol | Endpoint Format | Status |
|---|---|---|
| OPC UA | opc.tcp://host:port/path | Fully supported |
| Modbus TCP | host:port | Configuration supported |
| CAN Bus | Interface name + baud rate | Configuration supported |
| REST API | https://host/path | Configuration supported |
| Edge Device | Edge-managed reference | Configuration supported |
| Custom | User-defined | Generic JSON config |
See the Protocols section for protocol-specific details.
Connector lifecycle
- Created — connector is configured with protocol, endpoint, and settings
- Attached — connector is linked to one or more assets
- Bound — variables on attached assets have bindings to connector data points
- Active — edge gateway is collecting data through the connector
- Deleted — connector is soft-deleted (data preserved, can be restored)
Connector inheritance
When you attach a connector to an asset, all descendant assets in the hierarchy automatically inherit that connector. This means you do not need to attach the same connector to every individual asset.
Pump 001 (connector attached — direct)
├── Drive Motor (connector inherited)
├── Seal Assembly (connector inherited)
└── VFD Controller (connector inherited)Inheritance follows these rules:
- Direct attachment — explicitly attached to a specific asset
- Inherited attachment — automatically created for all descendant assets
- Override — a descendant can replace an inherited connector with a different one by creating a direct attachment (see Override mechanism below)
- Cascade — detaching a connector from a parent removes inherited attachments from all descendants, but preserves any direct attachments on descendants
Override mechanism
When an asset inherits a connector from its parent, you can replace that inherited connector with a different one. This is called an override. The override creates a direct attachment of the new connector on the target asset and removes the inherited attachment of the old connector from the target and all of its descendants.
For example, suppose a production line has a plant-wide OPC UA connector inherited by all machines. One machine connects to a separate local PLC instead. You override the inherited connector on that machine with the local PLC connector. The machine and its sub-components now use the local PLC connector, while the rest of the production line continues to use the plant-wide one.
Production Line (Connector A — direct)
├── CNC Machine 001 (Connector A — inherited)
├── CNC Machine 002 (Connector B — direct override)
│ ├── Spindle Motor (Connector B — inherited)
│ └── Coolant System (Connector B — inherited)
└── CNC Machine 003 (Connector A — inherited)Before applying an override, the platform shows an impact preview that includes:
- The number of assets affected (the target asset and its descendants)
- Any variable bindings that reference the old connector and will be deleted
- Any variables that will become unbound as a result
If bindings will be deleted, a confirmation prompt is displayed. The override operation is transactional — it either completes fully or not at all.
See Overriding an inherited connector for the step-by-step workflow.
Asset movement
When an asset is moved to a new position in the hierarchy, its inherited connectors are recalculated based on the new parent:
- Inherited connectors are replaced — the asset loses inherited connectors from its old parent and receives the inherited connectors of its new parent
- Direct attachments are preserved — any connectors explicitly attached to the moved asset remain in place
- Orphaned bindings are cleaned up — if the move causes an asset to lose a connector, any variable bindings that referenced that connector are removed
This ensures the connector inheritance tree stays consistent after structural changes to the asset hierarchy.
Health status
Each connector tracks its current health:
| Status | Description |
|---|---|
| Unknown | Initial state — health has not been checked yet |
| Healthy | Connector is functioning normally |
| Degraded | Connector is operational but experiencing issues (e.g., intermittent timeouts) |
| Offline | Connector is not reachable or not responding |
Health status is displayed as a colored badge on the connector in both the connectors list and the connector detail page. See Health Monitoring for more details.
Connector and asset relationship
The relationship between connectors and assets is many-to-many:
- A connector can be attached to multiple assets
- An asset can have multiple connectors (for example, one OPC UA connector and one Modbus connector)
- Each variable on an asset is bound to one specific connector through a binding
You can manage attachments from either direction — from the asset detail page or from the connector detail page. The connector-side workflow supports attaching to multiple assets at once.
Connector (OPC UA Server)
├── attached to: Pump 001
│ ├── var: discharge_pressure → binding → ns=2;s=DischargePressure
│ └── var: flow_rate → binding → ns=2;s=FlowRate
└── attached to: Pump 002
├── var: discharge_pressure → binding → ns=2;s=DischargePressure
└── var: flow_rate → binding → ns=2;s=FlowRate