Definition
FTU (Feeder Terminal Unit, feeder terminal) is a core device of distribution network automation, installed at 10kV and below feeder switches, used to collect electrical quantities such as voltage, current, power, switch status, and fault current, and to execute remote control switching commands issued by the master station. FTU communicates with the distribution master station via optical fiber, public wireless network, or private network to achieve distribution automation functions such as fault location, fault isolation, restoration of non-fault areas (FA), and load transfer.
FTU follows international standards such as IEC 61850, IEC 60870-5-104, and national standard GB/T 35697, with capabilities of three remotes (telemetry, remote signaling, and remote control). In scenarios without fiber coverage, such as overhead lines, rural networks, and remote mountainous areas, 4G/5G IoT SIM cards become the main communication method for FTU. IoT SIM cards provide FTU with reliable, low-latency remote communication, meeting the distribution network automation requirements for real-time performance (typically requiring remote control response time < 5 seconds) and reliability.
Technical Features
The FTU adopts an industrial-grade design, suitable for outdoor working temperatures of -40°C to +70°C, and features lightning protection, moisture resistance, and electromagnetic interference resistance. It has a built-in fault detection algorithm that can identify transient and permanent faults, working with the master station to achieve local or centralized FA. Some FTUs support distributed intelligence and can still perform fault isolation based on local logic during communication interruptions.
Use Cases
FTU is widely used in urban distribution network automation, smart grid construction, rural network renovation, industrial park power supply, etc. Typical scenarios include: overhead line fault location and isolation, cable line ring main unit monitoring, load monitoring and forecasting, remote control operations, DMA submetering and loss analysis, distributed generation grid monitoring, etc. In the context of new energy access and increasing electric vehicle charging loads, FTUs work with AMI and load management systems to support refined operation of distribution networks.
SimtoLink provides FTUs with IoT SIM cards, dedicated APNs, VPDN private networks, and smart grid solutions, ensuring stable, safe, and controllable communication for distribution automation.
Delay Budget for Remote Open and Close
What the three remote messages mean for the IoT SIM
When a feeder terminal uses an IoT SIM, the point is to carry telemetry, indications, and remote control from a pole-mounted switch or a ring-main unit that has no fiber, up to the distribution master station. Telemetry is voltage, current, and power. Indications are switch position and fault flags. Remote control is the open or close command from the master station. The SIM does not decide whether a fault is transient or permanent. That belongs to the terminal's own algorithm and to feeder automation at the master station. What the SIM must guarantee is that the command arrives within the agreed time, the result returns on the same path, and a communication break is not read by the terminal as "send the close again."
Public-network delay is unstable, so remote control usually uses several steps — select, checkback, execute — rather than one byte driving the coil. Any step that times out should stop in a safe state. A private network or fixed access narrows the exposure. VPDN describes how that differs from a direct public connection. Even on a private network, the radio hop can still drop packets because of obstruction, and local protection must not be removed.
When the public network may carry remote control
Use it where the line side has no reliable fiber, the terminal can isolate locally after communication is lost, and the master station can accept more delay jitter than fiber. The SIM should stay registered, the address or access point should be fixed, and the master station should accept only known terminals. Outdoor heat, storms, and tree cover change the antenna environment. Retest after the switch body is installed, not with a handheld sample at the foot of the pole. Size the plan for the telemetry interval plus an occasional command, so a "zero-traffic reclaim" rule does not suspend it.
Remote-control permission must be confirmed both at the master station and at the terminal. If the SIM is lost or the module is removed, device-SIM binding should stop that module from registering again, so a pulled communication board cannot be used to fake an online unit. For a weak rural site, state clearly whether it is telemetry only, with no remote control, or whether another bearer is required. Do not write "remote control" in the document when the site cannot close the switch.
A repeated close that operates the switch by mistake
A common failure is an unconditional resend of a close after timeout. The first command had already executed. Only the checkback was lost. The second close operates the switch again and, together with logic at the other end of the line, moves the wrong device. Another is treating a healthy heartbeat as a healthy control channel. Telemetry is still flowing, but the select and execute messages are dropped because of length or priority. If the master-station clock and the terminal clock differ by too much, event order reverses and the fault section is assigned to the neighboring segment.
Plugging an office SIM into the terminal as a temporary bridge mismatches the allow-list and the encryption. The link comes and goes, remote control succeeds only sometimes, and the fault cannot be reproduced. An antenna inside the switch cabinet drops off the network when the door is shut. Acceptance with the door open never sees it. The test should include: no second close when checkback is lost, registration with the door closed, and local logic that can still isolate the faulted section for days after communication is lost.
The timestamp on telemetry and the timestamp on remote control must refer to the same event. After fault current appears, if the telemetry packet uses the terminal clock and the checkback uses the master-station clock, a difference of a few seconds makes the isolation look as if it happened before the fault. The terminal should synchronize time regularly. A failed sync must not stop protection. It should only mark the clock as suspect in the message. When several terminals on one line share a data pool, they all report at the moment of a fault. Size the pool's concurrency for that simultaneous rate, not for the quiet average. Otherwise only the terminals closest to the master station get their messages out, the far terminals' fault flags are dropped, and the location is biased toward the wrong section.