Protocol traffic stays local
Equipment or edge view
Place an instance close to the devices it models and let it operate independently.
operational questionlive + modeled
Can this register change proceed without conflicting with maintenance or dependent equipment?
useful answer
Read the device state where it lives, relate it to asset identity and current work orders, then issue only the write the protocol actually supports. Kubling respects Modbus semantics instead of pretending a register has a database row lifecycle.
live state
relationships
valid action
Industrial operations
Control stays near the process. Context reaches the wider operation.
OT state should not lose its physical context on the way to an application or an agent. Kubling can model device data locally, then federate only the operational view needed above it.
The systems involved
Access each protocol at the equipment boundary. Bring operating context to it.
At the equipment boundary
Modbus TCP
Register-backed device state and supported register writes
SNMP
Network and equipment state exposed as a model
federate
In the wider operation
Maintenance systems
Work orders, ownership and operating restrictions
Upstream Kubling
Plant, region or fleet-level operational context
From register to operation
A register becomes useful when the model says what it belongs to.
Protocol limits remain explicit as Kubling adds the asset and operating relationships needed above them.
Read locally
Handle protocol traffic inside the segmented network, near latency-sensitive equipment.
Add operating context
Relate raw registers and device identifiers to assets, work orders and dependencies.
Preserve source semantics
Use Modbus UPDATE for writable registers. INSERT and DELETE remain unsupported because the protocol has no such lifecycle.
semantic pathbounded
registerdescribesasset_state
assetpart_ofproduction_cell
assetdepends_onnetwork_device
work_orderaffectsasset
setpointbounded_byoperating_rule
Deployment topology
Federate the model upward. Leave device traffic at the edge.
System
Domain
Federate edge instances
Plant or domain view
Build a broader model without moving every protocol interaction to a central collector.
Cross-domain
Ask only the wider questions
Multi-site view, if required
Connect plants or regions when a fleet-level decision needs them.
System, domain and cross-domain describe roles in a topology, not products you must deploy as a fixed stack. A Kubling instance can use local providers, federate other Kubling instances, or do both.
Available now
Build from current capabilities.
Read live Modbus state, write supported registers and federate that context with the rest of the plant while protocol traffic stays close to the equipment.
01
Modbus data source
Maps holding registers to typed tables, reads live state and writes supported registers through UPDATE.
02
SNMP data source
Makes SNMP-managed equipment queryable beside other operational systems.
03
Kubling federation
An edge instance can remain autonomous and become a source for a parent operational model.
Start with proof
Prove it with one source. Grow without changing the execution model.
Query and mutate through a local provider, then replace the source when you are ready. The engine still plans against the same schema and capability contract.