Old Soldiers Never Die
Amid Hum, Heat, and Dirty Power, Why SDLC still Demands Respect inside a Traffic Cabinet
In the belly of a traffic signal cabinet, silence is never really silent. There’s a low hum from power supplies, the faint warmth rising from relays just cycled, and the invisible but constant churn of electromagnetic fields bleeding from switching transients and load coils. It’s not a clean environment—it’s electrically noisy, thermally unstable, and saturated with EMI that would make consumer-grade hardware flinch.
Here, shielded cables don’t just look professional—they’re survival gear. Differential signaling isn’t a spec sheet brag—it’s a necessity.
And yet, tucked between terminal blocks and ground buses, SDLC over RS-485 continues its quiet watch. No glamour. No silicon fanfare. Just bit frames with Cyclic Redundancy Check (CRC), dispatched with unwavering rhythm.
In an era obsessed with edge computing, gigabit Ethernet, and IP-over-everything, this protocol SDLC—born decades ago—still commands respect. Not because it can do everything, but because it does the one thing that matters: deliver data deterministically, reliably, and predictably in a place designed to challenge all three.
In traffic cabinets, SDLC longevity is not a flaw—it's a credential.
This post explores some of the engineering reasons why “legacy” protocols like SDLC over RS-485 are still active guardians of field reliability. And why, in the places where failure isn’t an option, old soldiers like SDLC never die—they just keep doing their job.
SDLC Background
Synchronous Data Link Control (SDLC) is a bit-oriented synchronous protocol developed by IBM in the 1970s. It operates over serial links, providing reliable frame-based communication with CRC error detection and deterministic timing. Widely adopted in industrial and traffic systems, SDLC enables robust master-slave communication over physical layers like RS-485.
In NEMA TS2 cabinets, SDLC runs at 153.6 kbps over a multidrop RS-485 bus, linking the Controller Unit (CU) to devices like the Malfunction Management Unit (MMU) and Bus Interface Units (BIUs) via poll-based, collision-free communication.
In ATC cabinets, the SDLC communication is extended via two high-speed serial buses—SB1 and SB2—each capable of supporting up to 32 devices at 614.4 kbps. By routing cabinet communications through SB1 and SB2, the system enables faster device polling and enhanced integration across in-cabinet components, including the Controller Unit (CU), Cabinet Monitoring Unit (CMU), and Serial Interface Units (SIUs).
Across both systems, SDLC serves as the deterministic backbone for reliable in-cabinet communication.
Determinism and Temporal Order: SDLC’s Promise
Let’s step inside a traffic signal cabinet. At first glance, gigabit Ethernet seems like a natural fit: multiple devices, growing data needs, and seamless IP integration.
Yet the reality is far less forgiving.
Unlike the controlled conditions of enterprise or office networks, traffic cabinets are exposed to EMI conditions—introduced by dirty power supplies, LED drivers, coils, inductive loads, and even nearby lightning activity. In this setting, signal integrity isn’t about protocol elegance—it’s about electrical physics.
Here, SDLC over RS-485 excels. Its low-frequency differential signaling naturally rejects common-mode noise. Its simple framing and CRC mechanisms keep messages deterministic and clean. And in ATC systems, SDLC is engineered into the architecture, with two buses (SB1 and SB2) running at 614.4 kbps—four times the speed of traditional NEMA TS2 systems.
They operate without switches, IP stacks, or link negotiation. Just clean, clocked, error-checked data in a tightly timed loop. Because SDLC is synchronously clocked, it guarantees not just deterministic data-frame delivery, but strict temporal order and bounded delay, ensuring that every frame arrives on time, in order, and without jitter.
Ethernet as a Fieldbus Replacement?
While SDLC delivers on determinism and reliability under harsh in-cabinet conditions, it’s fair to ask whether modern alternatives like Ethernet could offer a viable upgrade. As fieldbus technologies evolve, Ethernet frequently enters the conversation—not just for uplinks, but as a potential in-cabinet replacement. But does it really fit?
Not Off-the-Shelf
Ethernet boasts immense bandwidth, an enormous ecosystem, and global familiarity.
While it's excellent for office networks and cloud telemetry, its high-frequency signaling (ranging from 25 MHz to well over 125 MHz for 1 Gbps links) makes it inherently vulnerable to EMI for in-cabinet communication, which demands the temporal order and bounded delay of frame delivery.
ℹ️ Ethernet signals operating in the tens to hundreds of megahertz are prone to EMI, leading to degraded integrity and elevated error rates unless mitigated by meticulous shielding, grounding, and physical-layer design.
These necessitate specialized industrial Ethernet configurations for intra-cabinet communication, such as ruggedized connectors, hardened switches, and compliance with protocols such as Profinet or EtherNet/IP.
Industrial Ethernet is not an off-the-self solution that can be transparently migrated into traffic cabinet without pain (see the list of references below).
Cybersecurity Implications
Cybersecurity concerns still remain relevant even in isolated in-cabinet environments. Ethernet is used as a fieldbus replacement among co-located devices.
These setups typically operate within a physically confined environment, utilizing point-to-point links or star topologies with internal switches, deliberately omitting any uplink to a wider network. Devices may use static IPs or even bypass the IP stack entirely, exchanging data directly over Ethernet frames at the MAC or application layer.
The outcome is a self-contained Ethernet network that—under ideal circumstances—presents with no externally accessible attack surface. As such, conventional cybersecurity measures like encryption, firewall, or intrusion detection may be deemed unnecessary—due to presumed physical and logical isolation.
However, this isolation is only as strong as its weakest point—physical access and network pivoting become critical attack vectors:
⚠️ If cabinet access is not physically restricted, an attacker can exploit exposed Ethernet ports, plugging-in a rogue device to passively monitor in-cabinet traffic or actively manipulate communication.
⚠️ The dual-network interfaces within CU—one to the internal Ethernet fieldbus and another to an uplinked TMC network, can serve as a bridge, pivoting from the TMC uplink into the Ethernet fieldbus—seriously undermining separation.
Physical cabinet access control, strict interface separation, internal network segmentation and data frame encryption are essential safeguards to mitigate these risks. All add up to significant configuration drift, deployment complexity, and IT maintenance cost.
SDLC offers a strategic edge: minimal public tooling, low attacker familiarity, and an obscure domain-specific interface—all of which raising the exploit barrier by design. The table below summarizes these differences and highlights why, despite its age, SDLC still holds cybersecurity advantages inside the cabinet.
Timing, Timing, and Timing
When it comes to using Ethernet as fieldbus replacement, the engineering challenge is also on the timing consistency.
Ethernet’s asynchronous, best-effort delivery model introduces inherent timing uncertainty. Without protocol enhancements like Time-Sensitive Networking (TSN), it lacks guaranteed delivery order and bounded latency. This undermines the strict real-time requirements of traffic cabinet operations—such as SPAT reporting, conflict monitoring, and fail-safe state transitions—where timing consistency is essential.
Advocates of Ethernet fieldbus may argue that determinism is unnecessary—after all, the ATC’s Linux OS and application stack are not real-time systems. But this overlooks a key distinction: determinism at the communication layer remains essential.
Even if higher layers are best-effort, lower-level inter-device communication must ensure integrity, predictability, and timing consistency.
In traffic cabinets—where bounded latency and strict polling drive safety and control logic—in-cabinet communication determinism is foundational.
In ATC deployments, SDLC still owns the inside. It remains the deterministic backbone for in-cabinet communication—providing reliable, predictable timing for core logic operations that must remain consistent even when higher-level systems fail.
What about CAN?
The CAN (Controller Area Network) protocol is widely used in automotive and industrial control, and is mentioned in ATC 5301 as a possible option for in-cabinet communications.
However, it is not a practical replacement for SDLC in traffic cabinets:
Payload Limitation
Standard CAN frames max out at 8 bytes (CAN FD extends to 64), whereas SDLC routinely exceeds this, carrying richer data like switch states, detector calls, and diagnostics. Fragmenting SDLC messages across multiple CAN frames introduces latency and timing jitter.
Protocol Misalignment
SDLC is synchronous and clock-driven, ideal for deterministic polling. CAN is asynchronous and arbitration-based, which creates unpredictable delays under load.
Architectural Mismatch
SDLC supports multi-drop, full-duplex party-line configurations. CAN’s broadcast model, with priority-encoded IDs, is less transparent for strict polling control.
👉 While CAN excels in many embedded contexts, its payload constraints, timing unpredictability, and architectural mismatch make it ill-suited to replace SDLC in traffic signal cabinets.
Final Thoughts: Pragmatism Over Fashion
RS-485 and SDLC may not turn heads, but they weren’t designed to impress—they were built to endure.
They were designed for one thing: to survive and function in industry settings where durability, simplicity, temporal precision, and increasingly, cybersecurity resilience, matter.
They’ve endured decades of change, served through countless hardware generations, and remain steadfast—not because they’re modern, but because they work, safely and reliably.
Old soldiers never die—especially when the mission still demands their grit.
References
Decotignie, J. D. (2005). "Ethernet-Based Real-Time and Industrial Communications." Proceedings of the IEEE, 93(6), 1102-1117. DOI: 10.1109/JPROC.2005.849721
Felser, M. (2005). "Real-Time Ethernet - Industry Prospective." Proceedings of the IEEE, 93(6), 1118-1129. DOI: 10.1109/JPROC.2005.849720
Jasperneite, J., & Neumann, P. (2001). "Switched Ethernet for factory communication." Proceedings of 8th IEEE International Conference on Emerging Technologies and Factory Automation, Vol. 1, 205-212. DOI: 10.1109/ETFA.2001.996372
Skeie, T., Johannessen, S., & Brunner, C. (2002). "Ethernet in substation automation." IEEE Control Systems Magazine, 22(3), 43-51. DOI: 10.1109/MCS.2002.1003998
Andersson, L., Brunner, C., & Engler, F. (2003). "Substation automation based on IEC 61850 with new process-close technologies." IEEE Bologna Power Tech Conference Proceedings. DOI: 10.1109/PTC.2003.1304232
Werner, Mortz, Wiedner, Florian, Schwarzenberg, Christoph. Industrial Ethernet: Challenges and Advantages, https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2024-04-1/NET-2024-04-1_06.pdf, accessed May 11, 2025.
Ethernet in Harsh Environments, White Paper, https://www.newark.com/pdfs/techarticles/ondemand-August2012/BLACK-BOX-Ethernet-in-Harsh-Environments.pdf, accessed May 11, 2025
NEMA TS 2-2023 Standard: Traffic Controller Assemblies with NTCIP Requirements
ATC 5301 Standard: Advanced Transportation Controller (ATC) Cabinet Standard Version 02.02
Networking Problems Caused by Electromagnetic Interference, https://www.cablewholesale.com/blog/index.php/2024/10/25/networking-problems-caused-by-electromagnetic-interference/?srsltid=AfmBOooUVjz19WdtHwF_JGLB_MlLPBRCiR8QNUob6ZU0GZq9Yp6A_GeP