LonWorks in Substations: LON Bus for Protection and Control

Almost every LonWorks page online is about air handlers and lighting. That’s half the story. LON was also a station bus in MV and HV substations. ABB built a whole protection and control range on it: REF 54x feeder terminals, REC and REM units, SPACOM relays behind gateways, and MicroSCADA on top.

Those systems are still in service. Many are now up for extension or migration. If you’re asked to add a bay, swap a relay or move the station to IEC 61850, you need to know how this bus actually works. This article walks through it the way you’d meet it on site.

For the protocol itself, see the LonWorks protocol pillar. Here we stay with the substation flavour.

What the LON bus does in a substation

ABB used the LON bus the same way as its older SPA bus, plus one more job.

• Vertical traffic. Bay devices push measurements, status and events up to the station level without being asked. MicroSCADA or a gateway reads and writes settings and parameters when it needs to.
• Horizontal traffic. Bay devices talk to each other directly. Bay controllers share interlocking states. Protection relays send blocking signals. This is the part SPA bus could never do, because SPA is a master-slave bus.

That second point is why LON mattered. Station-wide interlocking and reverse blocking over a serial bus, years before GOOSE existed.

A typical layout

The backbone isn’t the free-topology twisted pair that HVAC people know. The substation LON is a fibre-optic star.

Item	Typical value
Medium	Fibre optic, star topology
Default bit rate	1.25 Mbit/s
Hub	Star coupler (RER 111)
Device interface	LON interface module on a 9-pin D-connector, RS-485 levels
Station level	MicroSCADA (PCLTA card + RER 107), or a gateway such as COM610
Addressing	Subnet/node, no domain ID in practice
Limits	255 subnets, 127 nodes per subnet

The bay devices plug into star couplers. Star couplers can sit in two levels. Twisted-pair segments, where they exist, hang off a router card.

The hardware you’ll meet

These part numbers show up on old drawings and cabinet labels. Knowing what each one does saves a lot of guessing.

RER 111 star coupler. The hub of the network. It takes up to nine option cards:

• SFIBER: three fibre transceiver pairs for bay devices or for linking to another RER 111
• SRS485: connects devices with an RS-485 LON interface, plus one fibre pair
• SSLTA: serial LonTalk adapter for a PC or monitoring terminal
• SROUT: router card for twisted pair (TP/XF-78 or TP/XF-1250) and for splitting the system into subsystems
• SREDU: double connection, two fibre pairs to one device so a single fibre fault doesn’t drop it
• SLCM: LON clock master, takes a time reference and synchronises the network, with five sync methods for different device types

Power supply is single or dual, 80–265 V AC/DC or 18–80 V DC.

RER 103. Plugs into the RS-485 D-connector of an RE_ 500 device and converts to fibre. Works for SPA, LON and IEC 60870-5-103.

RER 107. A fibre transceiver that mounts on a PCLTA PC card. This is how MicroSCADA joins the LON. One or two fibre channels, glass or plastic.

RER 117. Same idea for a laptop with a PCC-10 card. This is the commissioning kit.

SPA-ZC 100 / SPA-ZC 102. LON/SPA gateways. They connect SPACOM relays and other SPA devices to the LON. The gateway polls the SPA device, and when data changes it sends it on the LON without being asked. The 100 takes power from the host relay. The 102 needs its own supply.

RER 115. A twisted-pair FTT-10A module for REC 523, REM 54_ and REF 54_. The LON port of the relay must be set to 78 kbit/s. It’s meant for small systems with low traffic and short distances, and must not be used to build a complete substation automation system. Response times are longer than on the 1.25 Mbit/s fibre bus, and devices using it should run acknowledged services. Discontinued since 2009.

Fibre rules that cause most faults

Two fibre types are in use, with very different limits. Mixing them up is an easy mistake on an old station.

	Glass	Plastic
Connector	ST	Snap-in
Fibre	62.5/125 µm	1 mm
Max length	1000 m	20 m
Wavelength	820–900 nm	660 nm

The 20 m limit on plastic is the one people forget. Plastic is fine inside a switchgear line-up. It is not fine between buildings.

Path rules for the whole system:

• A message from any device to any other device should cross no more than three star couplers.
• If you chain two devices through a dual-port interface module, the path should cross no more than six fibre lines.
• The maximum recommended distance between any two devices is 2000 m. In other words, two 1000 m glass links at most.

One more detail helps when you’re testing with a light meter. The interface modules and star couplers don’t echo light back on the port it came from. An idle device sends no light at all. So a dark fibre on an idle bus is normal, not a fault.

The D-connector pinout

When you need to check a LON interface module or build a test lead, this is the 9-pin layout on the device side.

Pin	Signal
1	DATA A (+)
2	DATA B (−)
3	RTS A (+)
4	RTS B (−)
5	COL A (+)
6	COL B (−)
7	GND
8	Service pin (TTL)
9	+5 V for the module

The module takes its power from the device through pin 9. A dead module can mean no supply from the device, not a broken fibre.

How the data is split: network variables vs explicit messages

LonTalk gives you two ways to move data, and the substation use is very clear about which goes where.

Network variables carry short, frequent data: measurements, status, interlocking and blocking signals. A network variable holds up to 31 bytes and is addressed by a 14-bit selector in the range 0 to 12287. More on the mechanics in the network variables article.

Explicit messages carry longer data: time-stamped events and reads and writes of device data, including setting values. Up to 229 bytes of data per message. Whole setting files go over the LonTalk file transfer protocol instead.

Control commands can use either one: network variables, or explicit messages in ABB’s AFD format.

The data formats used for network variables are simple:

Type	Size	Scaling	Example
Analog	32 bit	×1000	1.05 sent as 1050
Analog	16 bit	×100	1.05 sent as 105
Digital	16 bit	none	one or more bits, or a hex value
Bit write (BWR)	16 bit	none	sets or resets one bit of a 16-bit string

Byte order is most significant byte first. The 16-bit digital format lines up with standard types like SNVT_count and SNVT_state, which matters when you bind to a third-party device.

Not every device accepts every type. Check types when you bind, not after the interlocking fails a test.

The message codes on the wire

ABB uses the “foreign message” range of LonTalk explicit messages (codes 40H to 4FH) for its own formats. If you capture LON traffic on an ABB station, these are the codes you’ll see:

Code	Content
40H	LSG format event messages (time-stamped events)
41H	Transparent SPA-bus messages
43H	LSG format configuration messages (gateway setup)
4AH	DMP messages
4CH	AFD messages

SPA over LON (41H) is the one worth understanding. The full SPA message, start character, checksum and carriage return included, rides inside a LonTalk explicit message. Both the request (R or W) and the reply (D, A or N) use 41H. That’s how parameter data reaches a SPACOM relay through the LON, with the relay itself still speaking plain SPA.

Long SPA messages are cut into pieces of 45 bytes at most. Each piece except the last ends with &, CR, LF. Send one SPA request at a time and wait for the reply before sending the next.

Events (40H) carry an event type, a 16-bit object address, 32 bits of data and a timestamp down to hundreds of microseconds. Event types cover SPA-bus events (normal, analog and extended), analog events (32-bit, ×1000), and digital events with a 16-bit change mask plus the 16-bit value.

Which service type for what

LonTalk has four transport services. In a substation they’re not chosen freely.

• Acknowledged: most messages.
• Unacknowledged repeated: one sender, many receivers.
• Unacknowledged: clock synchronisation.
• Request/response: network management and network variable polls.

Getting interlocking and blocking through on time

A busy bus during a fault is exactly when blocking signals matter. Two settings make the difference.

Priority channel. Every device that sends interlocking, blocking or clock sync messages needs a priority channel assigned. Priority is reserved for those message types only. Don’t put measurements or events on it.

Collision detection. It’s optional on the bus, and not every device supports it. Devices that send interlocking or blocking messages should use it. The interface module detects a collision when the device holds RTS active while light is arriving on the receiver, and reports it on the COL pair.

With collision detection and priority both in place, delivery stays deterministic under heavy load.

Performance numbers to plan with

These figures assume 1.25 Mbit/s and an average packet under 10 bytes. Real numbers depend on the devices, gateways and routers in the path, so treat them as a starting point for a load check.

Figure	Value
Bus load	up to 500 packets/s
Load one node can handle	up to 300 packets/s
Acknowledged messages received per node	up to 150/s
Acknowledged messages sent per node	up to 70/s
Transfer time with CD and priority, no routers	under 20 ms
Best case transfer time	about 6 ms

Watch the 70 messages per second send figure. A device sending a burst of events after a disturbance, plus its interlocking traffic, uses that budget from one node.

Buffers are usually 66 bytes so small devices can share the bus. Long explicit messages go out in 32 to 45 byte pieces.

To keep the bus healthy:

• Keep frequently sent data short.
• Split long messages.
• Give nodes, gateways and routers as many buffers as they allow.
• Use router cards to keep busy subsystems’ internal traffic off the main bus. This mainly protects the higher-level devices, like the station computer, from overload.

Time synchronisation over LON

Clock sync is a two-step broadcast. The master sends nv_warning, then nv_clock right after it.

• The gap between the two must not exceed 100 ms.
• Below about 30 ms, a large share of clock messages get missed.
• So the usable window is 30 to 100 ms. nv_warning itself carries the delay value.
• The default selector for both is 2FFFH, which is 12287, the top of the selector range.
• nv_clock carries year, month, day, hour, minute, second, and a 16-bit field for milliseconds and hundreds of microseconds.

On a station with an SLCM card in the star coupler, that card is the clock master. If some bays drift while others stay in time, check that the warning-to-clock delay isn’t set below 30 ms before you suspect the time reference.

Engineering tools

The network is configured with LonTalk network management messages. On ABB stations the usual tool is the Lon Network Tool (LNT 505). It lets you build the configuration offline and download it later, use symbolic names for nodes and variables, bind network variables with SNVT support, and configure SPA-ZC 100 gateways. The tool handles up to 700 nodes per network.

Keep the LNT project file with the station documentation. Rebuilding bindings from a running network without it is slow work.

The relays and the LAG profile

REF 541, 543 and 545 feeder terminals take LON on the rear X3.3 connector, set through the protocol parameter for that port. Their parameter lists also include LON SNVT inputs and outputs, and virtual LON inputs for the control logic. REF 543 combined LON with its built-in logic to cut hardwiring between feeders. It’s been inactive as a product since 2022, so spares are a real question on old stations. REF 543 can also reach IEC 61850 through the SPA-ZC 400 adapter, which matters for migration.

Some ABB devices use the LAG 1.4 profile (LON Application Guide). It’s ABB’s own application profile on top of LonTalk, and it’s what gives horizontal interbay communication and station-wide interlocking between those devices. You’ll see it as “COM-L (LON – LAG 1.4)” on REF 542plus, and the 670 series has a LON protocol manual with a horizontal communication section.

“LON” on a relay datasheet does not mean it’ll talk to any LonWorks device. LAG is an ABB profile. Check that both ends speak it.

Extending or migrating a LON station

Three routes, roughly in order of effort.

Add a bay on LON. Possible if the star coupler has a free port or slot and you can still get a device with a LON interface. Do the load check above, assign priority if the new bay sends interlocking, and update the LNT project.

Gateway to a new SCADA. A station gateway with a LON-LAG master on the process side can pass the data up as IEC 60870-5-101, IEC 60870-5-104 or DNP3. COM610 is one example. This keeps the bay level as it is and replaces only the top. It does not give you IEC 61850 at bay level.

Relay-by-relay IEC 61850. Some LON-era relays have an IEC 61850 adapter, like SPA-ZC 400 on REF 54x. Useful to bring old bays into a new IEC 61850 station without replacing the relay.

Full IEC 61850 retrofit. The interlocking and blocking that ran over network variables move to GOOSE. Map every bound network variable to a GOOSE signal before you touch anything. The LNT bindings are your source list for that map. Miss one and an interlock you never knew about disappears.

During a staged migration, both buses run at the same time. Plan the interlocks that cross from a LON bay to a GOOSE bay. That boundary is where things go wrong.

FAQ