Microprocessor controllers and their architecture

Quayside Tower's four passenger cars are run by four controllers in a row of cabinets beside the top landing, each the size of a tall locker. Priya opened car 2's cabinet and named what Tamsin was looking at from top to bottom: a main processor board with a small display and four buttons, two input and output boards, a safety board with its own green and amber lights, a power supply shelf with 24 V DC supplies and a battery for the controller's memory, contactors and the brake control module, terminal strips for the hoistway and traveling cable, and on the right the variable-frequency drive with its own keypad. "Everything the Tillicum controller does with a hundred and forty relays, this does with those boards," she said. "The trick is knowing which board does which job."

The parts of a microprocessor controller

Every maker arranges its controllers differently, and the names on the boards vary, but nearly all modern elevator controllers have the same building blocks.

• The main processor board, or car controller, runs the car's program: call registration, direction, door control, the run sequence and most special operations. It stores the job parameters, the fault log and the event log in memory that keeps its contents without power.
• Input and output boards connect the processor to the outside world. Inputs read switches and sensors, such as door limits, leveling sensors and inspection switches; outputs drive relays, lamps and other devices. Many cars move most of their inputs and outputs out to boards on the car and in the hall fixtures, connected by serial links; Lesson 5 covers them.
• The safety board, on many current cars, reads the safety circuit and door circuits, supervises the door zone and leveling with doors open, and controls the safety contactors. On cars where safety functions are done in electronics, this board is certified to a safety integrity level and has two processors checking each other; Lesson 6 covers it.
• The drive is a separate unit, usually with its own processor, that turns the controller's speed command into motor current. It connects to the controller by a serial link, by analog and digital signals, or both, and it reads the motor encoder to control speed and position.
• The power section holds the main and brake contactors, the brake control module that lifts and holds the brake, the line filters and the control transformers and supplies.
• The group controller, on a group of cars, assigns hall calls to cars. It may be a separate processor, or one car's controller may act as the group while the others stand by to take over if it fails.
• A service tool interface lets a mechanic read the controller's state and logs and change parameters, either through an on-board display and buttons or with a handheld tool or laptop.

What the processor does in a scan

A controller's processor runs its program in a repeating loop called a scan. In each scan it reads all its inputs, works through its logic, and updates all its outputs. A typical elevator controller scans every few milliseconds to a few tens of milliseconds. Fast scans matter for anything that changes quickly, such as the moment the car enters a door zone, but the parts of the controller that must react fastest, such as opening the safety circuit, do not depend on the main processor at all: the safety devices are wired in series and drop the safety contactors directly, and the safety board has its own, faster, monitoring.

The main processor also runs a watchdog. A watchdog is a timer, usually in separate hardware, that the program must reset in every scan. If the program stops, for example because of a software fault or a failed memory chip, the watchdog runs out and forces the outputs to a safe state, which drops the run and brake outputs and stops the car. On many boards a watchdog trip lights a lamp or writes a fault the next time the board starts. A car that occasionally stops for no reason, with a watchdog or reset fault in its log, may have a failing board, a failing power supply, or electrical noise from a poor ground or an unshielded encoder cable.

# How far does the car travel before the brake grips, if a stop is commanded by software?
speed = 8.33          # rated speed
scan_ms = 10         # program scan time
relay_ms = 25        # output relay and contactor drop-out time
brake_ms = 120       # brake mechanical delay until shoes grip
total_s = (2 * scan_ms + relay_ms + brake_ms) / 1000    # worst case: change just missed by one scan
travel = speed * total_s
print(f"delay before braking starts: {total_s * 1000:.0f} ms")
print(f"travel at rated speed in that time: {travel:.2f} ft")
print(f"share of that travel caused by the scan: {speed * 2 * scan_ms / 1000:.3f} ft")

delay before braking starts: 165 ms
travel at rated speed in that time: 1.37 ft
share of that travel caused by the scan: 0.167 ft

Most of the delay is the brake's mechanical response, not the processor. That is one reason the code's tests of stopping distance in ELV-230 are done on the finished car, with the real brake, rather than calculated. The scan adds an inch or two at most.

Software, parameters and versions

A microprocessor controller's behavior depends on three things that are not visible on the prints: the software, the parameters and the hardware revision of each board. The software, often called firmware, is the program written by the maker. The parameters are the job-specific settings entered at installation and adjustment: the number of floors and their heights, door times, which special operations are enabled, the car's rated speed and the drive's tuning. The hardware revision is the version of each board, which matters because a spare board of a different revision may need a different software version.

Northcrest keeps a record for every microprocessor car with the software version of each board, a saved copy of all parameters after the last adjustment, and the board part numbers and revisions. When a board is replaced, the mechanic confirms the new board's software version matches or is approved by the maker for the car, loads the saved parameters or confirms them one by one, and runs the tests required after the change. A software update is treated as an alteration of the controller by many regulators if it changes a safety function, and Northcrest follows the maker's notice for each update on whether tests and a permit are needed.

# Compare the controller's current parameters with the last saved set
saved = {"floors": 30, "door_hold_s": 3.0, "nudging_s": 20, "rated_speed": 500,
         "fire_main_floor": 1, "fire_alt_floor": 2, "park_floor": 1, "level_offset": 0}
current = {"floors": 30, "door_hold_s": 4.5, "nudging_s": 20, "rated_speed": 500,
           "fire_main_floor": 1, "fire_alt_floor": 3, "park_floor": 1, "level_offset": 2}
changes = [(k, saved[k], current[k]) for k in saved if saved[k] != current[k]]
print(f"{len(changes)} parameters differ from the saved set:")
for k, a, b in changes:
    print(f"  {k:<16} saved {a!s:>6}   now {b!s:>6}")
if any(k.startswith("fire") for k, _, _ in changes):
    print("a fire service parameter changed: retest Phase I recall before return to service")

3 parameters differ from the saved set:
  door_hold_s      saved    3.0   now    4.5
  fire_alt_floor   saved      2   now      3
  level_offset     saved      0   now      2
a fire service parameter changed: retest Phase I recall before return to service

A comparison like this, run before and after any visit, catches changes made by other people and mistakes made during board replacements. At Quayside, the fire alternate floor had been changed to floor 3 during a building fire alarm test without anyone telling Northcrest. Priya traced it to a technician from the fire alarm company who had been given the service tool password, changed the password, and restored the setting after confirming it with the building and the fire alarm drawings.

Power supplies, grounding and noise

Most microprocessor controller faults that are not caused by a field device come from power and noise. The boards run on low-voltage DC supplies, typically 24 V DC for inputs and outputs and lower voltages on the boards themselves, fed from a control transformer. A supply that sags when the drive starts, or that has failing filter capacitors, can reset the processor or make inputs flicker. Variable-frequency drives switch large currents thousands of times a second and radiate electrical noise; encoder cables, serial links and analog signals must be shielded, with the shield grounded at the end the maker specifies, usually only one end, and run separately from motor and brake wiring.

Priya's checklist for a car with unexplained resets or communication faults has five items: measure the control supplies with the car standing and while it starts, with the meter's min/max function; check every ground and shield connection is tight and where the maker specifies; check encoder and serial cables are not run beside motor leads; check the cabinet temperature, because boards that run hot fail early; and check the battery that backs up the controller's memory and clock, because a dead battery can lose the time stamps that make the fault log useful.

Proprietary and non-proprietary controllers

Some controllers are built by the elevator maker for its own equipment and can be fully serviced only with the maker's tools, documents and software. Others are sold by independent controller makers to any contractor, with tools and documents available to any trained mechanic. Building owners care about the difference because it decides who can maintain their elevators and at what cost. Northcrest services both kinds. At Quayside, the cars use a maker's controller under a warranty maintenance agreement that gives Northcrest the service tool and documents. At Larchmont, the car uses an independent controller with an on-board display. Many jurisdictions and owners now ask, when a controller is replaced, that the owner receive the tools, documents and passwords needed for any qualified contractor to maintain it, and this is one of the questions in ELV-430's lesson on modernization planning.

Inside the drive

The drive deserves a note of its own, because many apparent controller faults are drive faults and the other way around. ELV-210 covered how a variable-frequency drive works. In an elevator, the drive receives from the controller a run command, a direction and a speed reference, either as a pattern it generates itself from a few commands or as a speed curve streamed from the controller. It reports back that it is ready, that the motor is magnetized and holding torque, that it is running, and any faults. Before the brake lifts, the drive must prove it can hold the car with motor torque, so the car does not drop or roll back when the brake releases; this step is called pre-torque, and on cars with load weighing the drive is given the load in the car so it can apply the right torque. Lesson 8 covers the speed pattern itself.