A bus topology connects every device to one shared backbone cable instead of giving each its own line back to a switch. It is the shape behind RS-485 multidrop links, Modbus RTU trunks, and the classic fieldbuses that still run in the field today. This page explains how a bus works, why termination matters, and why serial buses survive in a world where Ethernet star wiring dominates.
Bus topology in one line: A bus topology is a network where all devices tap onto a single shared cable, called the trunk or backbone, and take turns communicating over it. It uses very little cable and is common in serial field networks like RS-485 and Modbus RTU, but the whole segment depends on that one cable and on correct termination at each end.
In a bus topology one length of cable runs the length of the installation and every device connects to it, either by tapping directly onto the trunk or by a short spur off it. There is no central switch deciding where traffic goes; instead all devices hear everything on the wire and pick out the messages meant for them. This is why the layout is often called multidrop: many devices dropped onto one shared line.
Because the medium is shared, only one device can transmit at a time. On an RS-485 bus running Modbus RTU, for example, a master polls each slave in turn by address, and the addressed device answers while the others stay quiet. This orderly, one-at-a-time conversation keeps a simple two-wire cable working reliably for dozens of instruments, but it also means total bandwidth is shared, so adding devices slows how often each one can be polled.
The appeal of the bus is how little cable it needs. Instead of home-running every device back to a panel, a single trunk snakes past each device and picks it up along the way. On a long run with equipment strung out over distance, that can mean a fraction of the wire a star would require, which is a real cost and installation saving on serial field networks.
A bus only behaves well when it is terminated correctly. On an RS-485 trunk, a terminating resistor at each far end of the cable matches the cable impedance and absorbs the signal so it does not bounce back down the wire as a reflection. Get termination wrong, with none, too many, or resistors in the wrong place, and the reflections corrupt data, producing the intermittent comms errors that plague poorly built serial networks.
Correct practice is one terminator at each of the two physical ends of the bus and none in the middle, with spurs kept short so they do not act as unterminated stubs. Bias resistors are also often needed to hold the idle line at a defined state so noise does not look like data. These small passive details are where a lot of field commissioning time goes, and they are the first thing an experienced technician checks when a Modbus RTU loop starts throwing timeouts.
The other structural weakness is that the trunk is shared and continuous. A break, short, or loose connector anywhere on the backbone can disrupt every device downstream of the fault, and a single misbehaving transmitter that jams the line takes down the whole segment. Unlike a star, where a bad cable isolates one device, a bus fault can be hard to locate because the symptom appears across many devices at once.
Even as Ethernet star wiring became the default for control networks, the bus topology never disappeared from the field. Enormous numbers of installed instruments, meters, drives, and sensors speak Modbus RTU or a fieldbus protocol over a two-wire RS-485 bus, and those devices keep working for decades. Ripping out a functioning multidrop loop to convert it to Ethernet rarely pays for itself, so buses persist simply because they already run.
There are also cases where a bus is still the sensible new choice. Two shielded wires can carry a Modbus RTU network over long distances at low cost, tolerate electrical noise well, and connect to the huge catalog of inexpensive devices that expose a serial port rather than an Ethernet jack. For a handful of meters or a string of simple sensors along a pipe or skid, a serial bus is often cheaper and perfectly adequate.
In practice most modern sites run both shapes side by side. The plant backbone and control room are Ethernet stars and rings, while serial buses live at the edges, gathering data from field instruments into a gateway or PLC serial port that then presents it upstream over Ethernet. Understanding the bus matters because so much real field data still originates on one before it ever reaches a switch.
In a SCADA system a serial bus is usually where raw measurements begin. A PLC or RTU acts as the Modbus master on an RS-485 trunk, polling each field device in turn, then presents the collected values upstream over Ethernet to a SCADA server or an edge gateway. That gateway is often the bridge between the slow, shared serial world and the faster Ethernet world that carries data to a control room or a cloud dashboard.
The shared, one-at-a-time nature of the bus shapes how fresh that data can be. Polling twenty devices over one serial line takes measurably longer than reading twenty devices on their own Ethernet links, so update rates on a busy bus are slower, and a stalled or noisy device can hold up the whole poll cycle. Anyone watching a remote site knows that a value's timeliness depends partly on how many siblings share its bus.
For remote monitoring this makes the gateway the critical point. It consolidates several serial buses, handles retries and timeouts on flaky trunks, and forwards clean, timestamped values to the cloud so field operators can see a whole pad from a phone. The bus stays close to the instruments where its cost and noise tolerance shine, and the gateway shields the wider network from the quirks of the shared wire.
Terminating resistors match the cable impedance at each end of the bus and absorb the signal so it does not reflect back down the wire. Without correct termination, reflections corrupt the data and cause intermittent communication errors. Best practice is one terminator at each of the two physical ends of the trunk and none in the middle.
A break, short, or bad connector on the shared trunk can disrupt every device downstream of the fault, and sometimes the whole segment. Because many devices fail at once, the fault can be hard to locate compared with a star, where a bad cable only affects one device. This shared-cable risk is the main structural weakness of a bus.
Yes, mainly in serial field networks. Huge numbers of instruments, meters, and drives speak Modbus RTU or a fieldbus over an RS-485 bus, and those installations keep running for decades. New serial buses are still chosen for long, low-cost runs to simple devices, while Ethernet star and ring layouts dominate the plant backbone.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.