How the UltraCab II Works: An Onboard Cab Signal Explainer

Wayside signals have one weakness that no amount of good engineering fixes: the engineer has to see them. Fog, curvature, a distracted moment at the wrong block, and the most carefully designed interlocking in the world is only as good as one human glance. Cab signaling closes that gap by bringing the aspect into the cab, and speed enforcement closes the next one by acting on it if the engineer does not.

The UltraCab II, usually just "UCII", is an onboard cab signal and overspeed protection unit originally developed by Harmon Industries.¹ The product line passed to GE when it bought Harmon in 2000,² then to Alstom in 2015,³ and now sits under the KB Signaling name.⁴ It is fitted to light rail vehicles, diesel multiple units and locomotives,⁵ and it is also the onboard platform underneath the E-ATC and ITCS train control systems.⁶ It does three jobs: it reads the coded track circuit through pickup coils, it tells the engineer what the code allows, and it applies the brakes when the train exceeds it. Public sources for the key points are in the notes at the end. This piece is a theory of operation at the engineering level: what is in the rack, how rail current becomes a code, how a code becomes braking decisions, and how a single processor is made trustworthy enough to hold the brakes off.

The track side, in one paragraph

A coded track circuit does not just carry steady current to prove the block is clear. The wayside switches the carrier on and off at a code rate, measured in pulses per minute, and each code rate stands for an aspect. The carrier frequency and the table of code rates are set per railroad: one commuter line, for example, uses a 100 Hz carrier and a table of 15 code rates between 64.5 and 306.4 pulses per minute.⁷ A steady carrier and the absence of any carrier are codes too, and both are restrictive. The current flows down one rail, through the wheels and axles of a train in the block, and back up the other. A pair of pickup coils, one over each rail ahead of the leading axle, sees that current as a weak alternating signal,⁸ and that is all the onboard unit ever knows about the signal ahead.

What is in the rack

The UCII is a card rack (the LCR, logic control rack) with three processor boards and a set of I/O boards around them.

Tap to enlarge The whole chain in one picture. The brakes stay released only while every stage keeps saying yes.

• DDSP, the cab signal receiver. An 80C186-family host processor and two Motorola DSP56001 signal processors. The host uploads each DSP's program over the DSP's parallel host interface at every power-up, configures it, and collects its reports; the DSPs receive the digitized coil signal on their synchronous serial ports.
• CPU, the vital computer. Another 80C186-family processor. It turns the received code into an aspect and a set of speed limits, measures speed, decides when to brake, drives the displays, and keeps the logs.
• CMPU, the communications board. A third 80C186 running a small cooperative scheduler. It takes the CPU's run-time log off the internal bus and sends it to the vehicle's event recorder over a serial link.
• TVO, the vital output module.⁹ It holds the brake circuit released, but only under a continuously renewed, keyed command from the CPU.
• GPI and GPO for discrete inputs and outputs: end selection or reverser, brake and relay feedbacks, vehicle type straps, display power, the NCP counter. The speed sensor and interlock boards carry 8254-style counters for the wheel sensors, a relay that selects which end's pickup coils reach the receiver, and a signal and speed simulator used by the departure test.

The boards share an internal CAN bus. The engineer's display (and on a locomotive, a crew display) sits on a second CAN bus of its own.

Hearing the code

The rail signal is weak, noisy, and riddled with traction harmonics, so the receiver, which the manufacturer describes as dual digital signal processing with simultaneous dual carrier operation,⁹ splits the work between the DSPs, which do signal processing on every sample, and the host, which does timing and decisions.

Tap to enlarge Signal processing on the DSPs, timing and decisions on the host.

On the DSPs

1. Band-pass filter. Each sample goes through a long, linear-phase FIR filter centered on the carrier frequency. Its coefficients are not built into the DSP program: the host downloads them at configuration time as part of a territory definition, after checking the block's own checksum.
2. Envelope. The filter output is rectified and smoothed by a short second FIR, giving a slowly varying measure of how much carrier is present.
3. On/off detection with hysteresis. The detector keeps two thresholds. The carrier turns on when the envelope rises above the upper one and off when it falls below the lower one, so a signal sitting near the threshold cannot chatter. The pick-up level comes from the configuration; the drop-out sits a few percent below it. The design also supports thresholds that track the signal at a configurable rate, which is how the same receiver can cope with very different track and coil conditions.
4. Carrier check. A separate counter counts half-cycles of the filtered signal, with its own hysteresis. A real carrier produces a predictable count for each second of on time; noise that merely happens to have energy in the passband does not.
5. Reporting. At every on-to-off and off-to-on edge, and periodically while nothing changes, the DSP sends the host a small framed report: which channel, which edge, how long the interval lasted, the mean envelope over it, and the cycle count. Every report is checksummed.

Each DSP actually runs two channels, two independent filter and threshold configurations applied to the same input, so a receiver can listen for more than one carrier or territory at once.

On the host

1. Debounce. A tentative edge only becomes real once the new state has lasted long enough. Shorter excursions are folded back into the surrounding interval, so a single blip cannot invent a pulse.
2. Code matching. Each code in the territory's table carries windows for the on time, the off time, the period, and the total time across a run of several pulses. The decoder declares a code only when the measured timing fits, and treats an ambiguous match between two codes as a fault. Steady carrier and no carrier are matched by duration alone.
3. Validity. A matched code is valid for a limited time and has to keep re-confirming. If the pulses stop matching, the code is marked lost, and a short hold may bridge a brief gap before it expires.
4. Plausibility. The host watches the DSPs as closely as the DSPs watch the rail: frame sequence and gaps, report types arriving in a legal order, cycle counts consistent with the interval lengths, and the two DSPs' views of the carrier agreeing.

Two of everything

The receiver is diverse end to end. DSP A feeds a primary decoder and DSP B a complement decoder; the two DSPs run separately built programs, each with its own differently encoded copy of the configuration. Several times a second the host sends the CPU a result record over CAN with both decoders' answers, complemented copies of the key fields, and a CRC. The CPU checks the CRC and the complements, rejects anything stale (a result has to be fresh within a fraction of a second), confirms that the receiver is armed with exactly the territory, threshold, and parameters it sent, and then runs two independent paths over the primary and complement halves. A code is believed only when both agree.

From code to speed limits

The CPU runs a fixed major cycle a few tens of milliseconds long, paced by a millisecond timer tick. Every cycle does the same work in the same order: mode logic, the receiver result, the odometer, the time-to-penalty supervisors, enforcement and the brake decision, the outputs, alarms, displays, brake feedback monitors, and the log. A cycle that overruns is itself logged.

The decoded code goes through two table lookups: one gives the next operating mode for the current mode and code, the other the aspect class. Each class carries four speeds.

Tap to enlarge One aspect, four speeds. The gaps are a few mph and differ by aspect and vehicle.

• the target speed shown on the two-digit display;
• a warning point just below it, where the overspeed alarm sounds;
• an overspeed protection point a little above it, where the penalty brake applies;
• on a DMU, an emergency point a little higher still.

The CPU carries separate tables for DMUs and locomotives, selected by vehicle-type straps that are checked against a copy in battery-backed memory, so a strap change cannot silently swap tables. Public safety filings describe the same arrangement: one software load for freight and commuter equipment, with the vehicle type set by the wiring harness.⁷ The same code can therefore allow a higher speed on a DMU than on a locomotive with longer stopping distances.

Downgrades and time to penalty

When the aspect drops, the CPU does not brake instantly. It holds the old class in force and computes a time to penalty (TTP): braking-curve objects track the distance remaining before the train must be at the new speed, and the TTP is that margin divided by the current speed, shown in seconds on the three-digit display.⁵ Denton County's PTC implementation plan, which covers its UCII-equipped DMUs, gives the same definition in plain terms: TTP is "the time, in seconds, that is left for the vehicle to travel at the currently measured speed before a PTC Electric brake needs to be requested" if the train is to stop within its limit.¹⁰ The engineer slows down, the countdown clears, and the hold releases so the new limit takes over. If the TTP reaches zero, the penalty applies. The alarm switches to a fast cadence in the last few seconds.

Penalty, emergency brake, and release

Each brake application carries one or more reasons, kept as bit masks and logged by name: overspeed, TTP expired, no end selected at speed, the wrong mode for the vehicle, a departure test suspended, a system check, start-up. On a DMU the penalty is a full service brake request to the vehicle's control unit; the emergency brake is the vital output itself.

Brake assurance (DMU): once a penalty has been requested for a few seconds, the CPU checks the deceleration every cycle. If the train is still moving and slowing by less than a minimum rate, it escalates to the emergency brake. A separate rule escalates if speed climbs by more than a few mph during a TTP penalty.

Release is automatic. Once the train is stopped, the brake has been requested and its feedback confirmed for a few seconds each, and an end is selected, the releasable reasons clear and the brakes release. A system-check reason does not clear this way.

Modes

• CAB. Normal cab signal territory with full enforcement.
• YARD. Restricted speed, entered on the yard code and kept through a loss of code.
• Non-cab (FNC). Operation outside cab signal territory at a fixed limit, where the vehicle and configuration allow it.
• No Code Proceed (NCP). With no usable code, the engineer can request a restricted speed with the NCP pushbutton. Each use pulses a mechanical counter, so NCP use is on the record.
• TRL (trail). A DMU standing with no cab end selected for about a second drops to TRL and applies the brakes; selecting an end for about a second brings it back.
• CAL. Calibration of wheel diameters, date, and time. Leaving it takes a reset.

The persistent mode is kept in battery-backed memory, so a unit that powers up in yard comes back in yard once the code confirms it. End selection decides which pickup coils the receiver hears and which display is powered; on a locomotive, the reverser plays that role, with a short latch so a centered reverser does not drop the direction while moving.

Speed and distance

Two independent wheel sensors, on separate axles,¹⁰ feed free-running hardware counters, read once per cycle at the cycle boundary. Each cycle's pulse count goes into a ring buffer, and:

• speed is the pulse count over the last second, times a constant built from the calibrated wheel diameter and the sensor's pulses per revolution;
• acceleration is the change in speed over the last second;
• distance accumulates per pulse, in feet.

The CPU enforces against the higher of the two speeds and only believes the train is stopped when both sensors read under half a mph. It flags the two sensors disagreeing, applies slip and slide handling, and runs an integrity test in motion: if one sensor's odometer advances a set distance while the other sees no pulses, the silent one is failed. The counters' own timebases are cross-checked every cycle against an expected count.

Making one computer trustworthy

A relay holds a circuit because current flows through its coil; take the current away and gravity drops it to the safe position. A processor has no gravity, so the UCII builds the equivalent in layers. Railroad safety plans describe this as a single processor using diversity and self-checking in the sense of IEEE 1483, with vital data held in true and complement form.¹¹ That argument has been questioned by the regulator. In a December 2018 letter granting one railroad's E-ATC system only conditional certification, FRA pointed out that "reactive fail safety techniques", a phrase from the railroad's description of the UCII, is not one of the safety assurance concepts listed in its rules (49 CFR part 236, Appendix C), and wrote: "Given the use of single processor for UCII safety critical functions ..., it appears that the rule has not been met."¹² The layers below are the substance of that debate: they are how a single processor is meant to earn the trust that two would otherwise provide.

• Two channels in one processor. Every safety-relevant value exists twice: an A copy and a B copy in a different encoding (a complement, an offset, or a timer that counts the other way), computed by separate routines. A table-driven comparator checks the pairs every cycle.
• Booleans that are hard to fake. A vital flag is not 1 or 0. True and false are two specific, unrelated bit patterns tied to the variable itself, so a stuck bit, a wild write, or a copy from the wrong variable reads as neither and is caught.
• A program-flow signature. Every vital routine adds its contribution to a running signature that must come out exact at the end of the cycle. A skipped, repeated, or reordered routine breaks it, and that alone is a critical fault.
• A keyed, dynamic output. Part of that signature becomes the key written to the vital output module before each command, alongside a complemented check byte. The output is not a steady level but a chopped drive, so the module's design intent is clear: a wrong key, a stopped chopper, or a missed cycle should leave it de-energized. The A and B channels each write their own half of the command, and both must say "release".
• Read back. The output state is read back every cycle; a mismatch that persists for a few seconds blocks every output.
• Energize to release. The default everywhere is "brake": at power-up, at the start of every brake decision, and after every hardware write. Only an explicit "no reason to brake, this cycle" energizes the output.
• Critical checks. A failed check drives the outputs to brake, logs and displays its number, and latches it in battery-backed memory with a complemented copy. The CPU then parks in a safe loop that keeps the watchdog fed and the check on the display. After a power interruption the latched check is replayed at boot; only a deliberate reset at the CPU clears it.
• Integrity at boot and in the background. Interrupt vector and memory tests, two independent checksums over the whole program image (rechecked continuously in the background), a dual-checksummed calibration record that falls back to safe defaults, stack guards, and a discovery pass that confirms the expected boards are in the expected slots.

Below the critical checks sit informational checks, which log a condition with a data word but do not stop the train, so a maintainer can see a degrading part before it fails.

The departure test

The departure test is started from the display at a standstill, in an ATP mode, with an end selected and no code present. It runs as a sequence of steps, each logged with a numbered result:¹³

1. software version and vehicle type;
2. an aspect sweep: for every aspect, the simulator injects the code into the receiver's input and drives simulated speeds into both speed channels. Each entry checks that the code decodes, that both speeds track within tolerance, and then the expected outcome: the warning at the limit, a penalty above the protection point, an emergency application above the emergency point, or a TTP that expires after a downgrade, followed by the brake feedback sequence;
3. the receiver's analog path and both pickup coils, by impedance;
4. both speed sensors, from the in-motion integrity results;
5. rejection of off-frequency, aliased, and weak signals, which must all decode as no code;
6. the displays and a memory test.

The verdict is PASSED only if every result passed. A test that cannot proceed is suspended with the brakes held, and the reason is shown.

Logs

The UCII keeps two records:

• a run-time log: one text line per event and periodically, with time, both speeds, acceleration, the code and aspect, the mode, every brake request and feedback, the alarm, the TTP, and the odometer. It goes to a serial port and, through the CMPU, to the event recorder;
• an internal event log: a ring of fixed-size binary records in battery-backed memory, power-fail safe, downloaded with a laptop tool during maintenance. Free text such as check messages is chained across several records.

Read with the theory above, a log answers most "why did it brake?" questions on the spot. The reason is on the line, and the speeds and aspect around it show whether it was an overspeed, an expired TTP, an escalation by brake assurance, or a system check.

The one idea underneath

Strip away the boards and the tables and the UCII rests on one idea from relay design: the brakes are released only by an active, continuously renewed "yes". The receiver has to keep confirming the code, both DSPs and both CPU channels have to keep agreeing, the program has to keep running in order, the output has to keep being keyed, driven, and read back. The moment any of that stops, the answer is "brake".

Footnotes

1. Harmon Industries, Form 10-K for fiscal 1995, filed April 1, 1996, describing the development of Ultra Cab after the 1987 Northeast Corridor accident. SEC EDGAR. Ultra Cab II already appears in Harmon's Form 10-K for fiscal 1994 (filed March 1995, the earliest Harmon filing on EDGAR), which lists "Ultra Cab and Ultra Cab II" among its carborne equipment and credits 1994 growth in part to "the HLC, VHLC and Ultra Cab II". SEC EDGAR. The fiscal 1996 annual report (filed March 31, 1997) adds the "unique patented antenna" that lets it work alongside AC traction locomotives. SEC EDGAR ↩

2. "GE Completes Acquisition of Harmon Industries, Inc.", General Electric press release, September 1, 2000. Harmon was combined with GE Harris Railway Electronics. SEC EDGAR ↩

3. "Alstom entirely refocused on rail as GE deal completed", Railway Gazette, November 2, 2015. Railway Gazette ↩

4. Knorr-Bremse completed its purchase of Alstom's North American conventional signaling business in September 2024. "Knorr-Bremse sees international signalling opportunities after $690m acquisition", Railway Gazette. Railway Gazette ↩

5. HNTB, "RTD LRT Signal System Upgrade Options", prepared for the Regional Transportation District (Denver), January 25, 2022. Describes the light rail fleet's "GETS UltraCab II Cab Signal system and ATS system", its cab codes, penalty brake application, and time to penalty display. PDF ↩ ↩²

6. FRA, "Type Approval (FRA-TA-2012-001) and System Certification for Amtrak's Incremental Train Control System", December 27, 2012: "The OBC is an enhanced version of the GE UltraCab II, augmented with GPS, displays, and additional interfaces into the locomotive." regulations.gov, FRA-2010-0029-0072. For E-ATC, see the FRA type approval FRA-TA-2013-01-A for Portland & Western. regulations.gov, FRA-2010-0073-0036 ↩

7. Portland & Western Railroad, "Westside Express Service Enhanced Automatic Train Control (E-ATC) Positive Train Control Safety Plan", Version 1.5, July 21, 2017, Volume I. Code rates, carrier, and vehicle type configuration. Other railroads use other carriers and tables. regulations.gov, FRA-2010-0073-0047 ↩ ↩²

8. For the problem of AC traction motor interference at the pickup coils, see Harmon Industries, US Patent 5,586,736, "Cab signal sensor with noise suppression", issued December 24, 1996, which uses paired coils to cancel traction motor noise. The patent does not name the UltraCab. Google Patents ↩

9. KB Signaling, "Ultra Cab II: Cab Signaling, ITCS & E-ATC Platform", brochure KBS0143 Rev 002. Lists the DSP receiver, dual carrier operation, redundant speed calculation, braking curves, onboard self tests, event logging, and a triple vital output card. PDF ↩ ↩²

10. Denton County Transportation Authority, PTC Implementation Plan, Revision 9.0, January 30, 2019: definition of time to penalty (section 3.3.8), and speed measured from two pulse generators on independent axles, with slip and slide detection (section 3.3.7). regulations.gov, FRA-2010-0074-0035 ↩ ↩²

11. Denton County Transportation Authority, E-ATC PTC Safety Plan, Revision 1.1, April 2, 2020. regulations.gov, FRA-2010-0074-0043 ↩

12. FRA letter to Portland & Western Railroad, "Conditional Certification of Its Enhanced Automatic Train Control System as a Vital Overlay System", December 28, 2018, Enclosure 3, comment 16. regulations.gov, FRA-2010-0073-0063. Cover letter: attachment 1 ↩

13. Norfolk Southern petition to FRA, January 25, 2002: "UltraCab features a built-in departure test that includes an automatic test of the impedance of the receiver bars." regulations.gov, FRA-2002-11633-0001. See also the FRA hearing transcript of May 31, 2007, where a GE product manager describes the departure test and continuous self diagnostics. regulations.gov, FRA-2006-24646-0010 ↩