Elevator Electrical Design Roadmap

Introduction

Starting an elevator R&D electrical design from scratch requires establishing clear standards and
procedures. This roadmap covers all essential aspects, from wiring routes and harnesses to control
systems and safety circuits. Each section includes best practices, relevant standards (IS 14665 in
India, EN 81 in Europe), and examples to illustrate the concepts. Proper tooling, version control, and
documentation methods are also highlighted to ensure a robust development process.

1. Electrical Routing Design

Designing the electrical routing for an elevator involves planning how cables run through the shaft
and cabin. A standard routing scheme should be created to ensure consistency across projects. Key
considerations include:

 Cable Path Planning: Route power and control cables along dedicated paths in the hoist way
(e.g. along guide rails or in cable trays) to avoid interference or damage. Typically, a traveling
cable connects the moving car to the fixed shaft wiring. Maintain slack loops or use a festoon
system for moving cables to handle car motion without strain.

 Separation of Circuits: Separate high-voltage power cables (motor leads, lighting supply)
from low-voltage control or signal wiring to reduce electromagnetic interference. For
example, run motor power cables in a separate conduit or opposite side of the shaft from
communication lines.5

 Securing and Protection: Use clamps, cable ties, and conduits to secure wiring along the
route and protect it from moving parts. All metal conduits and cable trays should be properly
grounded. Ensure bending radii of cables are within limits to prevent fatigue.

 Compliance with Standards: Adhere to IS 14665 and EN 81 requirements for wiring. For
instance, IS 14665 mandates that all lift wiring be insulated, protected, and properly
supported to avoid danger to persons. EN 81-20 (the modern elevator safety standard)
similarly requires safe routing and attachment of cables to prevent abrasion or snagging.

Wire Gauges and Colour Codes

Choosing appropriate wire gauge is crucial for safety and performance. Follow the guidelines of
standards and calculate based on current and length. For control circuits and lighting, typically use at
least 0.75–1.5 mm² (18–16 AWG) conductors for mechanical robustness over long runs, while motor
power cables may be much larger (e.g. 4–16 mm² or more) depending on motor rating. Remember
that longer cable runs incur voltage drop; mitigate this by increasing wire cross-section if needed. As
a best practice, “the longer the wire, the more voltage is lost – increasing the gauge boosts ampacity
and reduces voltage drop”.

Use standardized colour codes for all wiring to improve safety and maintenance. Per IEC/EN
standards, for example, green/yellow is reserved for the protective earth, blue for neutral
conductors, and brown/black/gray for three-phase AC lines. In India, wiring color codes generally
align with international practice: red/yellow/blue for phases (old code) or brown/black/gray (new
code), black for neutral (old) or blue (new), and green/yellow for earth – ensure your scheme meets
the latest local code. Control wiring can use additional colors (e.g. orange for safety circuit wiring or
interlocks, white for door sensor lines, etc.) but maintain consistency. Clearly label both ends of each
wire with identifiers. A sample color-and-gauge reference is given below:
Function Typical Wire Color (IEC/IS) Typical Gauge (mm²)

Protective Earth (PE) Green/Yellow (striped) ≥ 2.5 mm² (per code)

AC Main Phase Brown / Black / Gray (3-phase) 2.5–6 mm² (motor/power)

AC Neutral Blue 2.5–6 mm²

Control Circuit (AC/DC) Red or Yellow (common practice) 0.75–1.5 mm² (signals)

Safety Interlock Circuit Orange (dedicated, if used) 1.0–1.5 mm²

DC Power (+) Red 1.0–2.5 mm² (as needed)

DC Power (–) Black 1.0–2.5 mm² (as needed)

Table: Standard wire colour codes and typical cross-sections. (Always refer to the specific standard in
your region – e.g. IS:14665 Part 3 or EN 81-20 – for any mandated practices on color coding and
sizes.)

Routing Diagrams and Tools

Create detailed routing diagrams for the elevator cab and shaft in CAD software. These diagrams
should show the path of each cable bundle from the control cabinet, through the shaft, to the car
and doors, including support points. AutoCAD is suitable for 2D layout of cable runs in plan and
elevation views. For example, an AutoCAD drawing can illustrate how the traveling cable loops from
the car to a junction box in the shaft, or how wires route through the car top to the control panel.
SolidWorks (with SolidWorks Electrical 3D) or similar MCAD tools can be used to model the 3D
routing of harnesses in the elevator car and shaft structure. This is helpful to check clearances and
bending of cables in moving parts. By overlaying the wiring paths on mechanical drawings, you
ensure that the routing is feasible and well-integrated with the elevator’s structure.

When creating these diagrams, include reference designators for connectors and harnesses, and use
layers or line colours in CAD to differentiate power, control, and safety circuits. For clarity, add notes
or legends for wire types and any special instructions (for instance, “Run cable X in conduit along rear
wall of shaft”). A well-documented routing scheme will serve as the default for all new elevator
models, with modifications as needed per project.

2. Electrical Harness Design

An electrical harness is a bundled set of wires and cables, complete with connectors, that can be
installed as a unit. For an elevator, harnesses streamline installation of complex wiring. You should
design harness layouts for major parts of the system, considering different elevator configurations:
machine-room-less (MRL) elevators, hydraulic lifts, home lifts, etc.

Example of a pre-fabricated elevator wiring harness, bundled and tied with labeled connectors ready
for installation.

Harness Layouts for Various Configurations

 MRL Elevators: In MRL designs, the drive and controller are typically on the top of the shaft
or within the hoist way. The harness must connect the car to these components over a short
distance. A common harness in an MRL is the car-top harness, which connects the car roof
junction box to devices on the car (lighting, fans, door operator, etc.) and to the traveling
 cable. Because MRLs lack a machine room, ensure that harness routing to the control panel
(often mounted on a wall or in the door frame) is neatly planned. Harness bundles should be
flexible and secured along the car top to accommodate movement.

 Conventional Traction (With Machine Room): Here the main controller is in a separate
machine room. You will have a traveling cable harness running from the car to the machine
room through the shaft. Plan harness segments such as: a controller-to-shaft harness (from
cabinet to a junction box at the top of shaft), the traveling cable itself (flexible cable bundle
from that junction box to car), and an in-car harness (distributing signals within the car).
Modularize these harnesses with connectors so that each can be replaced or serviced
independently.

 Hydraulic Elevators: Hydraulic lifts often have the controller and pump unit at the bottom
floor. Wiring runs are shorter, but you must include harness wires for valve solenoids and
level sensors in the hydraulic circuit. Design the harness to connect the controller to the car
and to the hydraulic pump unit. Hydraulic elevators tend to have slower movement but can
still benefit from a traveling cable harness if the car moves significantly. Ensure oil-resistant
cable jacket if harness is near hydraulic fluids.

 Home Lifts (Residential): Home elevators are smaller and may have simpler wiring (often
single-phase supplies). Still, applying harness design can improve reliability. Design a
combined harness that includes all needed conductors (safety switches, door locks, lights,
alarm, etc.) in one bundle. Home lifts may come as kits – the harness design should allow
quick plug-in connections during installation.

In all cases, aim to have predefined harness sections: for example, a “shaft harness” that runs
vertically with branch connectors at each landing (for landing calls and indicators), a “car harness”
within the cabin, and a “machine-room harness” for connections inside the control panel. This
segmentation aids manufacturing and troubleshooting.

Connectors, Pin Configuration, and Bundling Practices

Use standard connectors to interface harness sections with components. Connector selection should
consider current rating, number of pins, environmental protection, and ease of assembly. For
instance:

 DIN connectors or circular metal connectors (per DIN standards) can be used for robust
connections to motors, door operators, or limit switches. They offer secure locking and are
industrially rated.

 Molex/MSTB connectors: For internal wiring and PCB connections in the controller or car
operating panel, use reliable multi-pin plug connectors (like Molex KK series for low-current
signals, or plug-in terminal blocks). Ensure they are keyed or color-coded to prevent mis-
mating.

 Automotive-style connectors: Many elevator manufacturers use automotive harness

connectors (from suppliers like TE Connectivity, Deutsch, etc.) because they are designed for
vibration, have locking tabs, and can handle moderate currents. These are suitable for
harnesses that may be flexed or serviced often.

Each connector in your harness design should have a pin configuration chart. Define pin numbering
and wire assignment clearly in drawings and documentation. For example, a 12-pin connector on the
car harness might allocate pins 1-2 for door open/close limits, pins 3-6 for safety chain series circuit,
pins 7-8 for speaker/comm, etc., while another connector handles lighting and fan power.
Standardize pinouts across all similar harnesses – this will avoid errors when assembling or replacing
parts.

When bundling wires into a harness, group wires by function and destination. High-current and low-
current wires should be in separate sub-bundles or at least shielded from each other. For instance,
group all brake and motor-related sensor wires together, separate from the group of indicator lamp
wires. Use braided sleeves or spiral wrap to bind wires neatly, and add strain relief at each end (such
as heat-shrink tubing that anchors the bundle as it enters a connector, or mechanical clamps near
connectors). Providing strain relief is crucial to prevent wires from flexing at the termination points –
components like grommets and cable clamps at anchor points help take the stress off the
conductors.

Additionally, include service loops (a small slack in wires) near connectors and moving parts to
reduce tension. The harness should be secured along its route using mounts or tie-down points (for
example, a harness running along the car top might be clipped to the car frame at intervals). All
harnesses must be designed to withstand vibration and movement: use flexible, multi-stranded wire
with appropriate insulation (PVC or PUR cables are common; PUR is often used for traveling cables
due to its flexibility and wear resistance).

Standardization is key – try to use common harness designs across models. This means using
standard lengths and connector interfaces where possible. “Use standard, common-use connectors
and components – it makes sourcing easier and avoids inventory duplication”. By creating an in-
house library of standard harness components, you can speed up development and ensure
compatibility.

In-house vs Outsourced Harnesses

Decide early whether harness manufacturing will be done in-house or by an external supplier. In-
house design and assembly gives you more control: you can prototype quickly, adjust designs on the
fly, and ensure quality by testing each harness. This is useful in R&D phase. If you have the capability
(crimp tools, testers, trained staff), building harnesses in-house for initial projects is feasible. Develop
detailed harness drawings and a bill of materials (wire lengths, connector part numbers, terminal
lugs, sleeving, etc.). It’s advisable to create a sample harness and fit it in a prototype elevator to
verify length and fit.

For larger scale or if you lack manufacturing resources, outsourcing to a specialized harness
manufacturer can be efficient. Many vendors specialize in elevator wiring harnesses and can produce
them with consistent quality. Provide them with your drawings and specifications (including required
standards like flame-retardant insulation per EN 81-20, or specific wire brand/types). Outsourcing
can save time on production and often ensures each harness is delivered fully tested (insulation and
continuity). However, maintain close communication for any design changes and consider the lead
time for ordering harnesses. A hybrid approach is common: do the harness design in-house (to own
the IP and flexibility of design), but outsource the bulk manufacturing once the design is finalized.
This way you can also competitively quote the harness build to multiple vendors.

Sample Harness Documentation

Always produce harness drawings as part of your documentation. A harness drawing typically shows
the bundle in a flattened form (often a formboard layout): it will depict connectors at the ends (with
pin numbers labelled), the routing of wires between them (sometimes with reference to branch
breakout points), and each wire’s colour, gauge, and label. For example, a harness drawing might
illustrate a “Car Top Harness” with one end connecting to the car junction box (connector J1) and the
other end fanning out to various car devices (connectors J2, J3 for door operator, light, fan, etc.).
Each connection is annotated (e.g. pin 5 of J1 goes to pin 2 of J2, carrying signal “Door Open Limit”,
using 0.5 mm² blue wire). This level of detail is needed for both assembling the harness and future
debugging.

To illustrate, Figure 1 below shows a simple harness segment: a coiled cable with grouped wires and
connectors at each end (in an actual design, each wire’s function would be labeled). Harness
drawings can be created with tools like AutoCAD Electrical (using the “Cable and Harness” features)
or dedicated harness design software. Ensure to include a table of components on the drawing
(connector types, contacts, wire types, lengths of each leg, etc.).

In summary, treat the harness like a sub-system of the elevator. By designing with proper pin
assignments, robust connectors, bundling techniques, and clear documentation, you’ll achieve a
reliable and serviceable electrical backbone for the elevator.

3. Controller Part Research

Modern elevator controllers are sophisticated and must comply with safety norms. Begin by
researching existing controllers and components used in the industry. This will inform your own
design and help identify reliable suppliers. Key components and sub-systems to consider are:

 Main Control Unit: the “brain” of the controller, typically a microcontroller-based board or
PLC that executes the elevator logic. It handles inputs (buttons, sensors) and outputs (motor
commands, brake control, indicators). Many controllers use redundant CPUs for safety.

 Motor Drive (VVVF Inverter): a variable-frequency drive that powers the hoisting motor. This
is critical for smooth acceleration and deceleration. Drives often include regenerative
capability and require proper sizing (typically 5–30 kW range for mid-size elevators). Some
controllers integrate the drive and control logic into one unit (known as an integrated
controller). For example, the Monarch NICE 3000 is an integrated elevator controller that
combines the elevator control logic and motor drive in one package. It features multi-CPU
redundancy and supports CAN bus and Modbus communication. Integrated units save space
and simplify wiring between the control board and drive.

 Main Disconnect and Protection: an elevator has an incoming breaker or switch (often an
isolator or MCCB) as the main disconnect. Downstream of that, use MCBs or fuses for branch
circuit protection: one for the drive, one for cabin lights/fan, one for control circuitry, etc.
(Standards require separation of certain circuits – e.g., lighting and fan supply must be
separate from motor supply.) Include an Emergency Power Off switch that cuts power in an
emergency.

 Contactors and Relays: although the drive electronically controls the motor, safety codes
often require electromechanical contactors as an added layer to disconnect power when the
elevator is not in use or during safety events. Typically, two contactors in series cut the motor
power (this is a requirement in some standards to have redundant isolation). Also include a
brake control relay/contactor to operate the motor brake coil. Ensure these are elevator-duty
rated.
  Safety Circuit Interfaces: the controller must interface with the elevator’s hard-wired safety
chain. This includes door interlock contacts, gate switches, safety gear switch, overspeed
governor switch, final limit switches, buffer switches, etc. Usually, these are wired in series
forming the safety circuit which when open will remove power from the drive and apply
brakes. The controller should continuously monitor this circuit’s status (often via a safety
relay or input module that detects if the chain is intact). Components here include safety
relays (which meet fail-safe design, like forced-guided contacts relays) that drop out if the
safety chain opens.

 Floor Positioning System: modern elevators use sensors to know the car position (e.g.
magnetic switches on guide rail, or a tape reader system). The controller has an input
module for these sensors (position pulses or floor level sensors) to manage levelling and
stopping accuracy. Some systems use an encoder on the motor for closed-loop control.
Ensure your design accounts for position feedback components and their interface (e.g. an
encoder input on the drive or controller board, and floor zone sensors for slowdown).

 Door Controller: Elevator doors are often driven by a dedicated door controller (like those
made by Fermator, Wittur, etc.). You can either incorporate door control in your main
controller or interface to a separate door operator unit. Many R&D teams purchase door
drive units (e.g., Fermator door operator) which come with their own controller; in that
case, you just provide commands (open/close) from the main controller. If designing in-
house, research door controller components (DC motors or VFD for door, safety light
curtains, door timing logic).

 Power Supply Unit: a regulated power supply for the controller’s electronics (typically
converting 230VAC to 24VDC and 5V/12V as needed). Use a UPS/battery backup for critical
functions like the alarm, emergency light, or a lowering device if required (some controllers
include an Automatic Rescue Device with batteries to move the elevator to the nearest floor
during power failure).

 Interface Modules: if using a modular approach, your controller may have separate PCBs for
different functions – e.g., a board dedicated to inputs/outputs (with optocouplers, filters to
handle field wiring), a communications board (for CAN or serial links to call stations), etc.
Research off-the-shelf elevator control boards from companies like Arkel or Monarch for
reference on modular design. For example, Arkel ARL-500 is a decentralized system with
multiple modules and uses CAN bus to connect them, which reduces bulky wiring.

As part of research, study products from established vendors:

 Monarch (MCTC) – known for integrated controllers and drives (e.g. Nice 3000+ series).
These often meet both European (EN 81) and Chinese standards. Monarch’s catalogs provide
insight into features like group control and remote monitoring support.

 Arkel (Turkey) – offers ARL series controllers which are EN 81 compliant, with features like
plug-and-play wiring and LCD diagnostic displays. Arkel documentation (e.g. ARL-500
manual) shows how they partition the system (main board, car operating panel board, etc.).

 Fermator – primarily a door system supplier; research here for door controllers and how they
interface (Fermator’s door operator manuals will detail the I/O signals and power needed).

 BLT – “Bluelight” and other Chinese suppliers offer controllers; looking at their specs (voltage
ranges, supported speeds, etc.) can help ensure your design is competitive.
  Indian Vendors – Companies like Bharat Bijlee, Johnson Lifts, etc., often use custom
controllers; see if any whitepapers or case studies are available. Also, Indian standards
require adherence to the Indian Electricity Rules and local lift acts, so ensure your researched
components have necessary approvals.

Make a list of potential suppliers for each component. For example: contactor – (Siemens or
Schneider elevator-rated contactors), VVVF drive – (Fuji, Yaskawa have elevator drives if not
designing your own), encoders – (Heidenhain, etc.), power supplies – (PULS or Phoenix Contact
industrial PSUs). Evaluate whether to buy or build each part. You might buy the motor drive rather
than design a VFD from scratch, especially initially. The same goes for certain safety modules (you
could use a standard safety relay unit).

By studying these existing solutions (Monarch, Arkel, etc.), you gain insight into both hardware
design and features expected by customers. For example, Monarch’s integrated unit notes inclusion
of CAN, GSM remote monitoring, and multi-CPU redundancy – indicating modern controllers often
have fieldbus comms and fault diagnostic capability. Arkel’s system emphasizes quick wiring with flat
cables and CAN bus to each floor, demonstrating an approach to reduce wiring complexity.
Incorporate the best practices from these into your design.

In summary, the research phase should yield: a list of required components/modules for the
controller, known solutions or reference designs for each, and preferred suppliers (Indian and
European) for sourcing parts. This will set a solid foundation before you move to designing your own
controller.

Example of an integrated elevator controller (Monarch NICE 3000) which combines the control logic
board and the drive in one unit. Such units come with ready connectors for wiring and built-in safety
features.

4. Controller Design: Step-by-Step

With background research in hand, you can begin developing the elevator controller itself. This is a
complex task, so a structured, step-by-step approach is essential. Below is a logical flow for
developing a controller from scratch:

Step 1: Define System Requirements – Begin by writing detailed specifications. How many floors and
entrances will the controller support? What speed and capacity (which influences motor power and
drive requirements)? What safety standards must it meet (EN 81, ASME A17.1, IS 14665, etc.)?
Define the control type (simplex, group of 2 elevators, etc.). For example, you might specify:
“Controller shall handle up to 16 stops, duplex operation, speeds up to 1.5 m/s, supporting both AC
gearless and hydraulic drives.” Include environmental requirements (temperature range, noise
immunity) and interfacing needs (will it connect to a building BMS, fire alarm, etc.?). Clear
requirements will drive the design decisions in hardware and software.

Step 2: System Architecture Design – Decide on the overall architecture of the controller system.
This includes hardware architecture (central CPU board with distributed I/O vs. single-board, etc.)
and software architecture (real-time scheduling, state machines for elevator logic). For hardware:
choose a suitable microcontroller or PLC platform that can handle the I/O count and has enough
processing power for scheduling algorithms. Many elevator controllers use dual microcontrollers for
redundancy or a fail-safe watchdog that brings the car to a safe stop if the main logic fails. Define the
I/O list: e.g., X inputs (each hall call button, each car button, door locks, limits, etc.) and Y outputs
(motor/brake control, door motor command, indicators, etc.). Plan for expandability – perhaps use
I/O expansion modules or a fieldbus for car/call panels so you aren’t running a separate wire for
every single button. For software: outline the major tasks – e.g., a task for car motion control, a task
for door operation, a scheduler for calls, a safety monitor task. Formulate a basic state machine for
elevator operation (Idle -> Moving -> Levelling -> Door Open -> etc.). At this stage, you also decide on
the communication protocol between parts of the system. Modern controllers often use CAN bus or
RS-485 serial networks to connect distributed components (like COPs and LOPs) to the main
controller. For instance, you might use CAN open or a custom CAN protocol for all car and landing
panels. CAN is robust and supports error checking – a plus for safety. If using CAN, design message
formats (e.g., an ID for hall calls, an ID for floor position messages, etc.). If using a simpler approach,
you might have multi-drop RS485 linking intelligent fixtures. Document this architecture in a block
diagram showing the CPU, I/O boards, network, and external interfaces.

Step 3: Schematic Design of Hardware – Now proceed to the electronic design. Develop schematics
for the controller board(s). Include: microcontroller or PLC circuits, power supply section, input
circuits (with proper opto-isolation or filtering for 110V AC signals from old style buttons or 24V DC
signals – whatever your system uses), and output drives (transistors or relays to drive indicators, a
brake coil, etc.). Pay special attention to the safety chain interface: these are usually wired in series
externally, but you should include a way to detect their status. Often a safety relay module is used; if
designing one, use redundancy (e.g. two relays in series) and monitoring contacts. Ensure that if the
safety circuit opens, the drive is immediately disabled (e.g., by removing an enable signal or power).
For motor control, decide if you integrate the VVVF drive or use an external drive. If external, your
controller board must provide interfaces like analog output (0-10V or 4-20mA speed command) or
digital serial control to the drive, and inputs for drive status/fault. Many modern drives allow CAN or
Modbus control – that could fit into your protocol design. Also design the communication interfaces
(CAN transceiver, RS485 transceiver chips, etc. on board). Include circuitry for things like an
emergency battery supply for the alarm bell and emergency light (often a small 12V battery on the
controller, kept charged, and a relay to trigger lights on power loss). Make sure to incorporate
protection: MOVs for surge, proper fusing of all I/O lines, and EMI filters on the drive supply if
needed. At the end of this step, you should have complete schematics for the controller hardware,
ready for PCB layout or assembly. It’s wise to do a design review against the initial requirements to
ensure nothing is missed.

Step 4: PCB Layout and Prototype Assembly – If designing custom PCBs, use PCB design software to
layout the controller board. Keep isolation distances as required by the voltages (e.g., keep high-
voltage sections like 3-phase input separated from logic areas). Provide test points and diagnostic
LEDs (like a heartbeat LED, indicators for inputs activating, etc., which are invaluable during testing).
Once PCBs are made, assemble a prototype of the controller. If using a PLC-based design instead,
assemble the PLC rack and modules accordingly, and wire them up in a test panel.

Step 5: Develop Control Logic (Software) – Parallel to hardware, start coding the controller logic. A
simple approach is to start with basic motion control and then add complexities. For example, first
implement single-floor runs: press a floor button, motor runs to that floor, stops, opens doors. Then
expand to multi-floor call handling and scheduling. Floor management logic is at the heart of the
software – this is the algorithm that decides which request to serve next and how. Initially,
implement a basic collective control: the elevator should respond to calls in an efficient order
(commonly, serve all requests in current direction, then switch direction – this is full collective
control). As a reference, elevator scheduling algorithms are often compared to the “SCAN” algorithm
(like a disk head going back and forth). Ensure that internal (car) calls and external (hall) calls are all
queued properly. Key parts of logic include: handling simultaneous calls, not skipping someone’s call,
and overwriting going requests when a new one comes in depending on direction. Implement door
control logic with safety checks: only open doors when at a floor and stopped; if door open button is
pressed, extend dwell time; if obstruction is detected (via door sensor or light curtain), re-open the
door. Program the safety interlocks: the elevator should not move unless all door locks are closed
and the safety chain is intact – verify these at each start of motion. If any safety opens mid-run, the
software should immediately command stop. Some controllers cross-check speed feedback vs.
command (to detect if the car is moving unintentionally and trigger safety gear).

 Tip: It’s helpful to break the software into modules: e.g., Motion control, Door Control, Call
Dispatcher , Safety Monitor. This separation makes it easier to develop and test each in
isolation. Simulate as much as possible: for instance, create a software simulator of elevator
movement to test your logic handling without hardware. On real hardware, use dummy
inputs (or a simulation mode) initially.

Step 6: User Interface and Feedback – Design how the controller will communicate status. This
includes the displays and indicators on the control cabinet (like a 7-seg or LCD display showing floor
position or fault codes) and communication ports for technicians (like an serial or USB for a debug
console, or Bluetooth if using an app for service). Also define the messages shown on car and landing
displays (this overlaps with COP/LOP design, see next sections). Ensure the controller software can
drive these: e.g., update the floor number display as the car moves, show direction arrows, etc.
Many controllers have a menu system for configuration accessible through a small screen or a
handheld terminal – decide if that’s in scope initially or a later feature.

Step 7: Testing and Iteration – Once hardware and basic software are ready, begin bench testing.
Start with unit tests: confirm each input triggers correctly (use test switches to simulate door locks,
etc.), verify each output (does the brake relay activate when commanded, etc.). Progress to
integrated testing: run the motor (possibly without full load, or using a smaller motor for testing) and
see if your speed control logic works. Use an oscilloscope or logic analyzer for checking timing (for
example, that you drop a safety relay within milliseconds of command, etc.). Expect to iterate – you
might find adjustments needed in the software (tuning acceleration curves, debouncing inputs, etc.)
or even in hardware (maybe you need a snubber on that brake coil after all, to avoid noise). Each test
should be documented. Over multiple cycles, refine the controller until it meets the performance
and safety requirements. Keep in mind real-world scenarios like power failure (does your backup
system kick in?), emergency stop activation, fire mode (if applicable in your specs, where the elevator
should return non-stop to a certain floor), etc., and test those.

Throughout these steps, ensure you incorporate safety best practices. For instance, follow the fail-
safe principle – outputs that command motion should default to a safe state. The software should
regularly sanity-check itself (is position sensor data plausible? if not, stop and fault). Use
independent safety where required: e.g., the speed governor and safety gear are mechanical
backups; your controller should not prevent those from doing their job by, say, keeping the motor
energized – design so that loss of power (or a safety relay drop) removes torque and allows safeties
to engage.

Document each step of the design. By the end of the process, you should have not only working
prototypes but also schematics, wiring diagrams, and flowcharts/state diagrams of the logic. This will
be invaluable for review and certification. Designing an elevator controller is an iterative process
spanning multiple domains (hardware, firmware, and algorithmic logic), but a disciplined step-by-
step approach ensures all aspects are covered in a systematic way.
(In developing the controller, remember the dual aspects of power wiring vs. control wiring. One
must handle high power for the motor and braking, and the other deals with logic and signals.
“Power wiring handles the heavy lifting of energy distribution to motors and components, while
control wiring ensures precise operation through relays, switches, and logic circuits”. Both need
careful design for an efficient and safe controller.)

5. Controller Design: Optimization

Once a basic controller is functioning, attention turns to optimization – refining the design for
efficiency, performance, and modularity. Here are key areas to focus on:

 Reducing Power Loss and Improving Energy Efficiency: Elevators can consume significant
power, so the controller should minimize losses. One major opportunity is using a
regenerative drive. Traditional drives waste braking energy as heat, but a regen unit feeds it
back to the building grid. Research shows that “regenerative drives work by using the energy
created as the elevator moves down to help power it going up, saving energy”. Implementing
regeneration can reduce energy consumption by 20–30%. Also consider using high-efficiency
power supplies (SMPS) for the control circuits instead of linear regulators that waste energy
as heat. Another aspect is reducing standby power: ensure that when the elevator is idle,
systems like cabin lights or ventilation can go into power-save (for example, dimming lights or
turning off the fan when not needed). Using LED lighting (discussed later in Lighting) also
cuts power usage. Optimize motor usage by fine-tuning the speed profile – a smoother
acceleration and deceleration not only improves ride comfort but also avoids drawing
excessive peak currents (which reduces I²R losses in cables and motor). Moreover, minimize
wiring losses by placing components optimally: in MRL elevators, having the controller near
the motor shortens the motor cable run (less copper loss). If a component generates heat
(like braking resistors for drives without regeneration), consider placing it where cooling is
effective or upsizing it to operate more efficiently. All these measures contribute to a
controller that wastes less energy as heat and thus operates cooler and more reliably.

 Improving Response Time and Performance: Elevator passengers value a quick and smooth
ride. The controller’s response time to calls and commands can be improved through both
hardware and software tweaks. On the hardware side, if using a network (CAN/RS485),
ensure communication cycles are fast – e.g., broadcast position and call status frequently
(every few milliseconds) so that the system feels responsive. Use interrupt-driven inputs for
critical signals (like safety triggers or door sensors) so they are reacted to immediately rather
than waiting for a slow scan cycle. On the software side, optimize the dispatch algorithm –
for example, incorporate predictive logic if possible (if the car is empty and someone calls
from far away, you might start moving pre-emptively if allowed, etc.). For multi-elevator
groups, algorithms can get complex (like dynamic sectoring, artificial intelligence-based
dispatch, etc.), but for a single car you can still refine: perhaps implement a “nudging”
feature – if doors are held open too long, gently start to close to prompt clearance. Another
angle is using faster processing for speed control: if you have an encoder on the motor, feed
that into a fast PID loop (possibly handled by the drive itself) for precise levelling. The result
is more accurate floor stops, reducing releveling time. Evaluate using advanced control
techniques like model predictive control for the motor to squeeze efficiency and speed,
though these may be longer-term optimizations.

 Modular & Scalable Design: A well-optimized design is modular – meaning you can upgrade
or change one part without overhauling everything. In hardware, this could mean separating
 the drive unit, main CPU board, I/O boards, and COP/LOP interface boards. For instance,
have a modular drive interface: today it might be a certain VVVF drive, but tomorrow if you
want to use a different model, only that module changes while the main board stays the
same (communication via a standard protocol). Similarly, if you design a group control
module (for multiple elevators coordination), it could be an add-on board that connects via
the network. Modular design also aids troubleshooting – each module can possibly have self-
diagnostics. Arkel’s ARL system exemplifies modular design: it has a main controller, plus
decentralized boards for each floor’s call stations, all linked by CAN bus. This way, adding
more floors is just adding more of the standard modules on the CAN line. Strive for such
scalability: if your base design is for, say, 8 stops, plan how it could scale to 16 or more
(maybe by adding an expander board or simply configuring software). Use common
interfaces – e.g., if COPs communicate via CAN, each COP is just a node with a unique ID and
the main controller doesn’t care how many as long as IDs are unique. This reduces redesign
for different elevator sizes. On the software side, modularity means writing code in a way
that new features (like a different door timing profile or an alternative parking strategy) can
be plugged in without major changes to core logic. Use configuration tables or settings so the
same code can run different elevator configurations (MRL vs hydraulic differences should be
parameters, not separate codebases). Keep the safety logic somewhat independent from
operational logic so that updates on one don’t risk the other.

 Heat Management and Component Sizing: An often overlooked optimization is thermal

management. Reducing power loss (first bullet) helps, but also actively design for heat
dissipation. If your control cabinet tends to heat up (due to the drive or power supply),
consider adding a thermostatically controlled fan or a heat exchanger. Cooler operation
prolongs component life, meaning your optimized design remains reliable over time. Choose
components with some safety margin in specifications – e.g., if microcontroller operating at
50% CPU load is good, 80% might be risky when things get busy; optimization might mean
upgrading to a faster micro or optimizing code to keep that margin.

 Cost Optimization: In R&D you might prototype with expensive dev kits and oversized parts.
When refining, look for cost-down opportunities that don’t compromise quality. Perhaps a
single unified board can replace two smaller boards (if you determined splitting wasn’t
necessary), or vice versa if a particular function can be an off-the-shelf module cheaply. Use
of standardized harnesses (from earlier section) also reduces cost in production and
maintenance.

In optimizing the controller design, it can be useful to benchmark – measure your controller’s
performance vs. a known good system. For example, measure door open-to-close cycle times, floor-
to-floor travel time, power consumption per trip, etc., and see if there’s lag or inefficiency anywhere.
Maybe the door dwell is too conservative – adjust it; or the start acceleration is too timid – you can
increase it within comfort limits to save a second of travel. These little improvements add up to a
better product.

Finally, consider future technology in your optimization: things like IoT remote monitoring, predictive
maintenance (monitoring motor current signatures to predict wear), or machine learning dispatch
are advanced topics but keeping your design flexible might allow adding such features later (perhaps
via a network connection to a cloud system). For instance, ensure your controller can transmit data
(fault logs, run counts) externally – either via a modem or at least an easily accessible port – so that
adding a remote monitoring unit is plug-and-play.
In summary, optimization is about making your controller design not only work, but work well. It
should be efficient in energy, quick in operation, and modular for upgrades. Every refinement should
be balanced with safety (never optimize at the expense of a safety margin) and reliability. This phase
might not have the excitement of making something new move, but it’s what turns a prototype into
a polished, competitive product.

6. LOP and COP Research

LOP (Landing Operating Panel) and COP (Car Operating Panel) are the user-facing parts of the
elevator electrical design. They house the buttons, switches, displays, and indicators that passengers
and operators interact with. Designing or selecting these panels requires understanding their
components and ensuring compatibility with the main controller. This section breaks down the
components of LOPs/COPs and how to interface them.

Components of COP and LOP

A typical Car Operating Panel (COP) (the panel inside the elevator car) contains:

 Floor Selection Buttons: numbered push-buttons for each floor served. These are usually
momentary, illuminated buttons. They may have integrated lamps (LEDs) that light when
pressed or when that call is registered. In many designs, these buttons should have braille
and tactile markings per accessibility codes (EN 81-70 in Europe, ADA in the USA).

 Door Control Buttons: “Door Open”, “Door Close”, and an “Alarm” (bell) button. Door
Open/Close allow users to override door timing, and Alarm rings a bell (and/or calls an
intercom) in emergencies. Sometimes an emergency stop switch might be present (though
modern passenger elevators often exclude manual stop switches except in freight lifts or
older designs).

 Display Panel: to show the position and direction of the elevator. Traditionally this could be
a segment display (e.g., 7-seg or 16-seg LED display showing floor number and arrows for
direction). Modern elevators often use LCD or dot-matrix displays that can show floor
number, moving arrows, and even messages or graphics.

 Indicator Lights: some COPs include additional indicators like an overload light (which
illuminates if too many people, often labeled “Overload” or just a symbol), a fire service
indicator (for Fireman’s mode activation), etc.

 Key Switches: depending on application, there might be keyed switches on the COP – e.g., a
fan on/off switch, light on/off, or a priority service key. In service or freight elevators, there
might be a toggle for attendant operation mode.

 Emergency Provisions: an intercom or phone is typically integrated or mounted near the

COP, with a call button to communicate with security/monitoring. There’s also an emergency
light (usually separate but near the COP) which comes on during power failure. The COP area
will house the electronics for these (e.g., a small PCB for the intercom).

The Landing Operating Panels (LOPs), located at each floor landing, typically have:

 Call Buttons: either a single call button (in simpler systems or at terminal floors) or two
buttons for “Up” and “Down” (at intermediate floors for direction selection). These are also
illuminated when pressed (to indicate the call is registered).
  Position Indicator: Some landing panels incorporate a digital indicator showing where the
elevator currently is, or arrows indicating approach direction. In many designs, hall position
indicators (hall lanterns) are separate fixtures above the door, rather than on the LOP itself.
But sometimes they are combined.

 Key Switches on Landings: certain landings might have special switches – e.g., a fire recall
switch at the lobby (to activate fireman’s service), a lockout key to disable the elevator from
that floor, etc., depending on building requirements.

All these components must comply with standards (for instance, button size, illumination, and force
as per EN 81-70 accessibility rules, which require braille and minimum diameter, etc.). Since this is an
R&D start, you may consider initially sourcing COP/LOP modules from established vendors to focus
on controller logic, then later design your own panels. There are many COP/LOP suppliers that
provide complete panels with wiring.

Interface Logic with Controllers

The way COPs/LOPs connect to the main controller can vary:

1. Hardwired Conventional Interface: In older or simpler systems, every button and light is
individually wired to the controller cabinet. For example, each COP button has a wire going to an
input on the controller, and each indicator light has a wire from an output. This can lead to a lot of
wires – e.g., a 10-story elevator with up/down at each landing and 10 car buttons easily has dozens
of conductors in the traveling and shaft cables. If going this route, use organized harnesses: typically
a traveling cable will have all the necessary cores (e.g., a 24-core traveling cable handling all car
buttons, etc.) and at each landing a separate bundle for that floor’s buttons. The controller needs
input cards with enough channels for every button. Outputs for lamps can be consolidated by
common return if using a lamp supply, or driven individually. The logic is straightforward: button
pressed -> input active -> controller logic registers call -> controller activates corresponding lamp
output (so the button lights up). You must ensure the voltage levels are matched (often buttons use
24V DC for lamps and signal). If any use 110V AC (some older systems for lamp circuits), you’ll need
appropriate interfacing (relays or opts). Hardwired interfaces are reliable but labour-intensive and
harder to modify.

2. Serial Communication Interface: Modern designs increasingly use serial communication to

drastically cut down wiring. Each COP or LOP has a small microcontroller board that communicates
with the main controller via a network (like CAN bus or RS485). Instead of 10 wires for 10 buttons,
you have just two wires (the communication pair) connecting that panel. The COP microcontroller
will scan its buttons and send pressed events to the main controller; likewise, the main controller will
send commands to light up the indicators or displays on that COP. For instance, Arkel’s system uses a
CAN bus running through the shaft with “plug-in” connectors at each floor for landing panels. Each
landing board listens on the CAN network for its address to light the call acknowledgment or arrow.
This distributed approach significantly reduces the bulk of cables (only the CAN pair and a DC power
pair run through the shaft for all landings). If you design this, you need to develop the
communication protocol: e.g., assign each device (each COP and LOP) an ID, and define message
types like “Hall Call(floor, direction)” from LOP to controller, and “Light Call(floor, direction, on/off)”
from controller to LOP, etc. CAN is preferred for its robustness in industrial environments and multi-
master capability (so multiple panels can talk). RS485 with a simple protocol (like Modbus or even
custom) can also work but requires handling bus contention if multiple devices talk – often a
master/slave scheme is used with the controller polling each panel in turn.
3. Hybrid (Multiplexed) Wiring: Another method is using multiplexers or matrix scanning to reduce
wires without fully smart panels. For example, the COP could be wired in a matrix (rows and columns
of buttons) that the controller scans – this reduces the number of conductors compared to one-per-
button. Or using small encoder/decoder ICs: e.g., each hall call could be connected via a binary
encoded scheme. However, these approaches are less flexible than a true serial comms and have
mostly been superseded by microcontroller-based panels.

Given you are doing R&D, implementing a serial link for COP/LOP early is wise as it’s the industry
trend. It will make your elevator wiring much simpler. Ensure to also plan how the displays interface
– if using CAN, you might have a dedicated message to update the floor display, etc. Or if the display
is basically driven by the COP board, then the main controller just sends it the floor number and
direction. Vendor compatibility is crucial: if you ever want to use a third-party COP (say a designer
fixture from Schaefer or MAD Buttons), check if they support a known protocol or if they expect
parallel wiring. Many third-party panels can work either way (they might offer both options).

If you decide to use off-the-shelf COP/LOP initially, find out what interface they use. Some might just
give you a bundle of wires (for which you wire to your inputs/outputs), others might have a CAN
interface. Contact companies for compatibility – for example, if you consider COPs from a supplier
like ECE or Wittur, ask if their panels integrate with controllers via CAN open-Lift or some standard. It
might be beneficial to adopt a known standard like CAN open Lift (an extension of CAN open
specifically for lift equipment), which defines device profiles for COPs, etc. That way any compliant
COP/LOP will talk to your controller.

Sample COP/LOP Schematics and Integration

To illustrate interfacing, consider a scenario of a serial-linked system: The controller has a CAN bus
running to all COPs/LOPs. On the controller schematic, you’d have a CAN transceiver and the bus
lines going to a “COP network”. Each COP’s schematic (if you design it) would show the
microcontroller reading button inputs (perhaps via its GPIOs or via I/O expander) and LEDs for
indicators driven by its outputs. For example, a COP board might use an 8-bit I/O expander to drive 8
segment outputs for the display. Your controller sends floor info to that board, which then outputs to
the display. Figure 2 (conceptual) might show: COP microcontroller connected to buttons B1..Bn and
LEDs L1..Ln, and a 2-wire CAN connection back to main controller. The main controller’s logic map
would know that when car is at floor X it sends a message to COP to display X, and when a button
press message comes from COP it treats it like a car call input.

In a hardwired example, a wiring diagram would show each COP button wired to a terminal block,
which then goes to the controller input. For instance, “Car Floor 3 Button –> Input I10”, and “Car
Floor 3 Lamp <– Output O5 (24VDC)”. The landing calls similarly: “1st Floor Up Button –> Input Ix,
Lamp <– Output Oy”. Often, to reduce outputs, lamp circuits are ganged by using a common “Call
Acknowledge” output that lights all call buttons that are active via the circuit (not individually
controllable, but acceptable in many cases). But modern practice is individual control for precise
feedback and easier troubleshooting.

One important part is compatibility of voltage and wiring: If your COP uses, say, 12V LED modules
for buttons, you must provide either a regulated 12V supply or appropriate resistor drives from 24V.
If the panel is third-party, follow their wiring diagram. For safety-critical lines like the alarm bell or
emergency light, these often have dedicated wires and power – e.g., the Alarm button might directly
energize a bell circuit in the controller, and the emergency light LED is wired to the controller’s
backup battery output (so it lights on power fail). Ensure those are accounted for in schematics.
Testing COP/LOP integration: When you have prototypes, test each button and indicator
systematically. If using serial comms, test loss of communication (what if a COP board fails – does the
rest still work and can the elevator still move? Ideally yes, minus accepting new calls from that
panel). Also handle priority: e.g., if someone presses the alarm, that should override or at least be
immediately attended (maybe by stopping at next floor). That logic often is in main controller but the
COP provides the input.

Remember also firefighters’ operation and other modes: typically, there’s a fire service key switch at
the lobby (on an LOP or a separate panel) that when turned, signals the controller to enter fire mode
(return car to lobby, open doors, then only allow keyed operation). These interfaces must be planned
(it could be simply another input or a more complex logic if per code it bypasses normal calls).

In summary, for COPs and LOPs: decide whether to make them smart (serial communication) or
simple (hardwired). Smart panels drastically cut wiring and are more in line with modern products,
but require a bit more development effort in electronics and protocol. Hardwired panels are simple
but result in bulky wiring harnesses. Given this is a fresh R&D start, implementing a serial link like
CAN will pay off. You can always make a temporary hardwired test panel for initial bring-up, then
migrate to the serial panels.

Ensure documentation for panels includes wiring diagrams or pinout tables. For example, if using a
particular connector between the car harness and the COP, document which pin goes to which
button/LED. If panels are swappable or if the building has multiple openings, ensure that’s
configurable (e.g., if front and rear doors, the COP might have separate door open buttons, etc.).

Finally, consider aesthetics and user experience: R&D should eventually also involve selecting
materials (stainless steel faceplates?), button styles (micro-movement or tactile feel), etc. Those
don’t affect electrical design directly but are part of the product. In terms of electrical integration,
those choices might affect whether you buy off-the-shelf button modules or design PCBs with LEDs
behind custom buttons, etc.

7. Lighting

Lighting in an elevator includes the cabin illumination and lighting in the shaft/pit for maintenance. It
also includes emergency backup lighting. Starting from scratch, you should plan for energy-efficient,
code-compliant solutions.

Cabin and Shaft Lighting Options

For the elevator car interior, modern designs use LED lighting almost exclusively. LEDs offer low
power consumption, long life, and low heat generation – important in the small, enclosed space of
an elevator car. Options for cabin lights include LED downlights (spot or flood lights recessed in the
ceiling), LED tube lights (as replacements for fluorescent tubes in older designs), or LED panels that
give a diffuse light. Some high-end designs use indirect cove lighting or color-changing LEDs for
ambiance, but from an R&D electrical perspective, the main focus is ensuring sufficient illumination
(lux level) and safe power supply.

In the hoistway, typically there is a requirement for a light in the pit and one on the car top (for
maintenance personnel). These are often simple utility lights (LED or CFL bulb) with a switch. The pit
light and car top light are usually powered from the building mains (through the elevator’s supply)
but separate from the elevator controller circuits.
Energy efficiency is key: using LED cabin lights can significantly reduce the cab lighting load (a LED
panel might consume 15–20 W vs. an equivalent old incandescent setup of 100+ W). Additionally,
incorporate an automatic turn-off or dimming: many standards require that cab lights and fan turn
off after the elevator is idle for a certain duration (to save energy). This can be controlled by the
controller logic or a standalone timer. For instance, after 5 minutes of no use, turn off half the lights
or dim them to a lower level, and turn off the ventilation fan, until a call is registered.

Another aspect is aesthetic vs. functional lighting: ensure whatever LED drivers or circuits you use
do not cause flicker (use high-frequency drivers or DC supplies). This is especially needed if you have
a CCTV camera in the cab – flickering lights can cause camera banding. Most LED drivers nowadays
are good, but it’s a point to note.

Integration of LED Drivers and Circuits

LEDs typically require low-voltage DC power (12V or 24V DC common, or dedicated constant-current
drivers). You have two approaches: use a distributed driver (e.g., run 230V AC to each light fixture
where a small driver module at the fixture converts to LED power), or a central low-voltage supply
(e.g., a 24V DC power supply in the controller cabinet feeding all LED lights in parallel). The central
supply approach makes it easier to integrate with emergency power (you can have one battery
backup feed the 24V lighting bus). However, voltage drop over long runs should be considered if
using low voltage – the traveling cable needs to carry the current for the LEDs. Usually, elevator LED
lights don’t draw too much (maybe 1–2 A for a set of LEDs), so a 24V, 5A supply could run multiple
fixtures.

Emergency backup lighting is a vital part: by code, an elevator car must have an emergency light that
automatically turns on if normal power fails, to prevent passengers being in darkness. This is often
implemented with a rechargeable battery pack and a dedicated emergency light fixture (or the main
lights themselves could have battery backup). A common solution is a small 12V sealed lead-acid or
modern Li-ion battery in the COP or above the cab, connected to an emergency light circuit. When
mains is present, the battery is trickle-charged; when mains goes out, the battery powers an LED (or
several) in the cab for at least the minimum required time (often 1–2 hours by code).

If you design this within the controller: Provide a charging circuit for a battery and outputs to an LED
lamp. Many elevator controllers include an “Emergency Light” output that is essentially a 12V battery
output that goes to a lamp in the COP. Alternatively, there are off-the-shelf emergency light units
that you can mount in the cab ceiling which contain their own battery and just need a 230V feed
(they will charge and auto-turn on in a power cut). Simpler for R&D might be to use a self-contained
unit initially.

For shaft lighting (for maintenance), typically not on UPS – it’s only on when a technician turns it on.
But cabin emergency light must be on UPS/battery.

Ensure all lighting circuits are properly protected (fused) and wired through the traveling cable as
needed. A typical scheme: a 230VAC feed from main supply goes through a car-top junction box
where it feeds the cabin light (through a switch on the car top that can turn off cab lights for
maintenance). That 230VAC also feeds a small transformer or LED driver for the lights. In your design,
you might instead feed a 24V DC line for lights via the traveling cable.

Standards compliance: Both IS 14665 and NEC codes require that car lighting be on a separate circuit
from the motor. This means in your wiring, the cab lights shouldn’t be powered from the same
breaker that runs the motor drive. Provide a dedicated MCB for “Cabin Light and Fan”. Moreover, EN
81-20 requires a minimum lux level on the car floor and in the shaft when lights are on (usually 50 lux
in cab, 20 lux in shaft, etc. – check exact values). Ensure your chosen lighting meets that by design
(e.g., number of LED downlights needed for the cab size). Also, all cab lighting fixtures should be
flame retardant and meet the fire safety norms (which likely they do if certified for building use).

Sample Lighting Circuit

To envision the wiring, consider this typical setup: There is a lighting circuit breaker in the machine
room or controller cabinet (say 6A MCB) feeding the cab lighting. From there, wires run via the
traveling cable to the car top, into a light switch (for maintenance use) and then to LED drivers and
the lights themselves. The emergency light is tapped before the switch (so it’s not accidentally turned
off) and connected to the battery unit. When power is on, the battery is charging; when power fails,
a relay or sensing circuit switches the light to battery.

For example, a wiring diagram might show: Lighting MCB -> [Car Lighting Circuit] -> Cabin Light
Fixtures + Emergency Light Unit. The emergency unit often has three connections: permanent live,
neutral, and switched live (for charging and sensing). In normal operation, it senses line voltage; if
lost, it closes its internal circuit powering the lamp from battery.

If we illustrate: the car has two LED downlights and one emergency combo light. The two downlights
are fed from 230VAC via an LED driver. The emergency combo has its own driver with battery. In
normal power, all three are ON providing illumination. In power failure, the two normal downlights
go off (no supply), but the emergency light kicks in from its battery. This way at least one light stays
on.

Alternatively, if using a central 24V system: you would have a 24V DC supply (likely backed by battery
or a DC UPS) feeding all LED lights. In that case, during power failure, that 24V is maintained by
battery, so possibly all lights stay on (maybe at reduced level to save battery). Some controllers do
this: they keep a couple of LEDs on via battery until rescue or power return.

Also include a fan in the circuit – cabin fan is often 230VAC (or 24V DC sometimes). It should also be
on the separate circuit (usually same as light circuit). It normally does not run on emergency power
(not critical). Provide an on/off control for the fan (a switch in COP or auto-off with idle).

One more aspect: Elevator shaft lighting – typically the shaft has its own lighting separate from the
elevator power (often on the building’s electrical system, turned on by a switch at the door or
machine room). In some cases, the specification might require you to include a outlet and light in the
pit and on the car top that are GFCI protected for workers. These are more installation details, but
ensure at least to plan that the car top will need an outlet (for plugging a work lamp or tools) and
that wiring might come from the controller or mains. As per code, that receptacle should be on a
GFCI (or RCCB) and a separate circuit.

Sample reference: IS 14665 (Part 2) explicitly states that “the supply to the car light should be from a
separate circuit, controlled by a switch in the machine room, independent of the power supply
mains”. We will follow that: so in our design, yes, a separate feed for lights, with a toggle switch in
the cabinet or nearby to isolate cabin lights.

Testing the lighting: measure the brightness, test the emergency light duration (simulate power loss
and see if it meets required time, e.g., EN 81-20 requires at least 1 hour of emergency lighting at
certain intensity). Also ensure the alarm bell is connected to battery or a UPS (the alarm, often a bell
or buzzer, must work during a power failure too). Many emergency light units include a buzzer or the
alarm could be separately battery-backed.
For visual documentation, you can include in your electrical drawings a simple schematic of the light
circuit. For example, a diagram showing the mains feed into a transformer/driver, feeding LED lights
in parallel, and a battery pack connected to one of them with a changeover relay. Mark the switch on
top of car that cuts lights for maintenance, and the fuse protecting the circuit. This helps installers
and future engineers understand how the lighting is powered and what to check if lights fail.

In summary, a robust, efficient lighting design for the elevator will use LEDs for low power usage,
provide adequate illumination, incorporate automatic shutoff for energy saving, and ensure an
emergency light comes on when needed. It’s often a simpler part of the electrical design compared
to controls or motors, but it directly impacts user comfort and safety. So it’s worth doing right, and
fortunately, standards provide clear guidance on the basic requirements.

8. Tooling and Software for Design, Version Control, and Documentation

Developing electrical designs from scratch benefits hugely from the right tools and solid
documentation practices. Here we outline recommended software tools for design and how to
manage versions and documentation in an R&D environment.

CAD Software for Electrical Design

 AutoCAD Electrical: This is a specialized version of AutoCAD tailored for electrical schematic
design. It provides an extensive library of electrical symbols (relays, contacts, switches, etc.)
and automation for wiring diagrams and point-to-point drawings. Using AutoCAD Electrical,
you can create schematics for your controller circuits, wiring diagrams for the elevator, and
panel layouts. It can generate reports like BOMs and wire lists automatically. Since it’s built
on AutoCAD, it’s familiar if you’ve used that, but adds intelligence (wires are objects that
know how to connect, components can be cross-referenced). It’s great for 2D schematics and
is widely used in industry for control panel design. One downside might be that it’s file-
based, so managing larger projects requires discipline, but it’s quite sufficient for most
needs.

 SolidWorks Electrical (2D & 3D): SolidWorks Electrical has two components – a schematic
design environment (2D) and an integrated 3D harness design within SolidWorks CAD. The
schematic part is similar in intent to AutoCAD Electrical (with symbols and connections, plus
an underlying database), while the 3D part allows you to route wires and harnesses in the 3D
model of the elevator. For example, you can place electrical components (controller box,
limit switches, lights) in the SolidWorks model of the elevator and then virtually route the
wires/cables, getting lengths and even auto-generating duct/tray fill calculations. This is very
useful to ensure harness lengths are correct and to avoid physical interference in the design.
SolidWorks Electrical excels in collaboration between mechanical and electrical designers –
changes in the schematic can reflect in the 3D model (wire added in schematic appears
unrouted in 3D waiting to be routed). Since elevator design has a significant mechanical
aspect (cab, shaft, etc.), using an integrated tool like this can reduce iteration time. However,
it’s a high-end tool requiring licenses and setup; it may be overkill if you’re just focusing on
schematics initially, but for harness and panel layout it’s powerful.

 EPLAN Electric P8: EPLAN is a very powerful electrical CAD software used in many European
companies for complex control systems. It is database-driven and highly configurable. EPLAN
can handle schematic design, generate detailed wiring lists, terminal diagrams, and even
nailboard layouts for harnesses. It’s known for enforcing consistency and automating tasks
(like you place a contactor coil, it can automatically generate the contacts, etc.). EPLAN has a
 steep learning curve and might be more than you need at the very beginning, but it shines
for large projects and version-controlled design. If you anticipate very large schematics or
integration with PLC configuration, etc., EPLAN is worth considering. It also has modules for
fluid power (if you had hydraulic circuits), but primarily you’d use the Electric P8 module.
One advantage is the vast device libraries and the ability to import manufacturer data (like
terminal blocks, cable types, etc.). Many industry folks say EPLAN is more efficient in the long
run, albeit with an initial overhead to set up templates and standards. Since you are starting
fresh, if resources allow, adopting EPLAN and building your standards from day one could be
beneficial, especially as the team grows – it prevents the “random drawing” syndrome by
enforcing norms.

 Other Tools: If you are developing PCBAs (printed circuit boards) for your controller, you’ll
need an EDA tool like Altium Designer, KiCad (open-source), or Eagle, etc., for PCB design. For
programming PLC or microcontroller, the appropriate IDE (like Codesys for PLC or an
Embedded C IDE for microcontroller) will be used – not exactly design tools but part of the
toolkit. For mechanical drawings of panels or enclosures, standard CAD (SolidWorks,
AutoCAD Inventor, etc.) will be used.

To summarize tool choice: For initial stages, AutoCAD Electrical is often the quickest way to produce
electrical drawings (schematics and wiring). As you progress, SolidWorks Electrical 3D can help
integrate with mechanical design, especially for harness routing in the elevator model. EPLAN is an
alternative if you expect to handle very complex documentation or want to follow European industry
practices strictly. Each has its pros and cons – for instance, one industry comparison noted “EPLAN is
better than either [AutoCAD or SolidWorks Electrical]... ACAD Electrical works but can be crude”,
whereas SolidWorks Electrical is great if you already use SolidWorks for mechanical. So consider your
company’s existing expertise and other departments.

Simulation and Analysis Tools

These are optional but useful: for example, using a circuit simulator (SPICE-based) for any custom
electronic circuits (like power supply design) can catch issues early. If you are dealing with
electromagnetic analysis (maybe ensuring the motor drive doesn’t interfere with comms), tools like
Ansys or MATLAB might come in. For software logic, a simulation in a tool like MATLAB/Simulink
(Stateflow for state machines) could help verify the elevator logic under various scenarios. However,
these are secondary to core CAD tools for documentation.

Version Control and Collaboration

As your design files grow, it’s critical to manage versions properly. Electrical designs (schematics,
drawings) should be under a version control system just like software. You can use traditional VCS like
Git or SVN for files (especially if using text-based or well-differenced formats). For binary CAD files
(DWG, etc.), a system like Autodesk Vault (for AutoCAD) or SolidWorks PDM can manage file check-
in/check-out with version history. If a formal PLM/PDM is not available, even using a structured
shared folder with versioned file names is better than nothing (but error-prone).

Consider a solution like Git LFS for CAD files or simply an internal server where people must
increment revisions. The key is to avoid situations where one engineer’s change accidentally
overwrites another’s, or you lose track of which version was sent to manufacturing. Many teams
adopt the practice: once a drawing is released (say for prototype build), tag it with a revision code
(Rev A, Rev B, etc.), and freeze that file (no edits without creating a new revision copy). Maintain a
change log that explains what changed in each revision.
For multi-disciplinary collaboration, cloud platforms can help: e.g., storing docs in a shared
repository (like a company SharePoint or Google Drive) with proper access. But these don’t replace a
true version control. Given the importance, “you need to use version control and backup systems
that record history and changes of your files, and let you recover older versions”. Loss of design data
can be catastrophic – always have automated backups of your CAD data (nightly backups to a secure
server, etc.). The LinkedIn advice above suggests tools like Git/SVN or even Dropbox for simpler
setups – what matters is that changes are tracked.

As an R&D startup, you might not have enterprise tools at first, but at minimum use something like a
private Git repository or set the project up on platforms like GitLab or Bitbucket (they can store
binaries, albeit not diff them nicely). If using SolidWorks Electrical or Altium for PCB, they have their
own collaboration features or can integrate with VCS.

Documentation Practices

Beyond just versioning, emphasize good documentation habits:

 Maintain a clear naming convention for drawings and files. For example, file names like
SCH_ElevatorController_MainBoard_REVA.dwg or Harness_Car_to_Controller_rev0.pdf
immediately convey content.

 Use document numbers if possible (some companies assign a document ID to each

schematic or manual). This helps keep track especially when you have many documents.

 Create a document index or tree: a top-level document (like an “Electrical Design

Document”) listing all the drawings, schematics, harness lists, etc., with their latest revisions.
This acts as a map for anyone looking into the documentation set.

 Write explanatory notes in schematics where non-obvious. For instance, include a note on
the schematic that “All wiring to COP is via CAN bus, see CAN bus network diagram for
details” or “Resistor R15 adjusted based on field test to limit LED current to 10 mA”. Such
notes are invaluable later on.

 Keep calculation records: if you compute something like the needed wire gauge (voltage
drop calc) or the braking resistor size for the drive, document that in a design notes
document. It can be informal, but store it under version control too. This helps when
someone questions a design choice – you have the rationale saved.

Use tables and charts in documentation for clarity. For example, include a table of all I/O points of
the controller (Input #, function, connected device) – this cross-reference is helpful during
installation and troubleshooting.

Sample Documentation to Produce

By the end of the design, you should have at least:

 Electrical Schematics for control circuits (multi-sheet schematic covering power distribution,
controller logic, safety circuit, comms, etc.).

 Wiring Diagrams showing how external components are wired to the controller (like a
diagram that shows every terminal and which cable/wire goes where, possibly in ladder or
point-to-point format).

 Harness Drawings for any harnesses (as discussed, a pinout and physical layout).
  Panel Layout drawing: how components (contactors, drive, boards) are arranged in the
controller cabinet or panel, with dimensions. Tools like AutoCAD or SolidWorks can be used
to make a scaled layout. This is needed for fabrication and assembly.

 BOM (Bill of Materials): a list of all components, from big (motor drive, controller PCB, etc.)
to small (connectors, terminals, cable types and lengths). Electrical CAD tools can often
output this automatically. It’s crucial for procurement.

 User Manuals or Wiring Manuals: Eventually, prepare documentation for installers or users.
An installation wiring manual might illustrate where to connect each part (e.g., how to wire
the door lock to the controller terminals). Also, a brief user manual for the controller,
explaining LED indicators, how to do basic configuration, etc. At R&D stage, this might be a
later deliverable but keep it in mind.

Managing Changes

When changes occur (and they will, especially in R&D as you test and modify), follow a change
process: update the drawing, increment the revision, and add a note in a revision block about what
changed. Communicate changes to the team (e.g., “Harness H1 pin 3 changed from +24V to +12V –
updated in Rev B drawing”). This avoids confusion where someone might use an old print. It’s helpful
to have periodic design review meetings where everyone syncs on the latest updates, and perhaps
maintain a “change log” document.

As a final point, because you are starting from scratch, it’s an opportunity to instill a culture of
thorough documentation and controlled design. It might seem like overhead initially, but as the
project grows (and new team members come or certifications require evidence of design control),
these practices pay off. It also makes troubleshooting in the field much easier when you have reliable
documents to refer to.

By following this comprehensive roadmap – covering routing, harnesses, controllers, panels, lighting,
and utilizing proper tools and practices – an elevator R&D team can establish a solid foundation for
designing safe, efficient, and maintainable elevator electrical systems. Each section of the design
influences the others, so maintain a systems view: e.g., a harness change might affect routing, a
controller feature might affect COP wiring, etc. Regularly update documentation and verify
compliance with IS/EN standards at every stage. With careful planning and iterative development,
you will progress from blank sheets to a fully functional elevator system prototype and beyond. Good
luck with your elevator R&D project!

References: The guidelines and examples above draw upon industry standards and practices. Key
references include IS 14665 (India’s elevator standards) for wiring and safety provisions, EN 81-20/50
(European standards) for modern lift safety and design rules, as well as insights from existing elevator
systems (e.g., Monarch integrated controllers, Arkel decentralized wiring). Best practices in wire

Here is a complete, end-to-end breakdown of all components in an elevator controller system,

including their function, working principle, and interaction within the system. This applies to most
modern VVVF-based elevator controllers like Monarch NICE1000+, Aybey AE-MAESTRO, and similar
systems:
Sl. Descriptio
Component Function Expanded Explanation
No n

This board contains a

microprocessor or
microcontroller that executes
all elevator logic: direction
control, dispatching, safety
Central
Main Control Brain of the checks, IO management, and
1 controller
Board (MCB) elevator communication. Think of it as
PCB
the CPU of the elevator system.
It governs how the elevator
behaves based on inputs from
sensors, buttons, and other
modules.

Converts fixed-frequency AC to
variable-frequency output to
control motor acceleration,
Controls
Variable speed, and deceleration.
motor
2 Drive (VFD) Frequency Enables smooth starts/stops
speed and
Drive and energy savings. Common
torque
models include NICE1000+, AE-
MAESTRO, or branded inverters
from Fuji, Yaskawa, etc.

Some systems use an

integrated microcontroller
(ARM, DSP) on the MCB; others
Embedded
Logic may use an external PLC (like
controller
Processor / computatio Siemens, Delta). It handles
3 or
PLC n and signal inputs, runs logic, and outputs
industrial
processing control signals. For example:
PLC
Door close only after all floor
sensors and safeties are
satisfied.

Ensures fast and reliable data

RS485 / exchange between car top unit,
Links sub-
Communicati CAN Bus / landing panels, COP/LOP, VFD,
4 systems
on Module Modbus / door operator, and service
digitally
Ethernet tools. Modern systems use CAN
or Modbus protocols.

5 IO Modules Interface Physical Inputs: limit switches, door

(Input/Outpu blocks for signal contacts, safety circuits.
t) sensors managemen Outputs: motor contactors,
and relays t indicator lamps, buzzers.
Digital inputs/outputs are opto-
isolated for reliability. Analog
IO is used in hydraulic systems
(e.g., pressure or temperature
Sl. Descriptio
Component Function Expanded Explanation
No n

sensors).

Usually mounted on motor

shaft or machine side. Provides
real-time feedback on shaft
Car position
Encoder / Rotary rotation to ensure precise
and motor
6 Resolver feedback positioning of the car. Encoder
rotation
Interface device pulses are interpreted by the
tracking
drive/controller for speed and
location. Resolver is analog;
encoder is digital.

The motor brake is a spring-

loaded mechanical clamp.
Brake Coil driver Engages or Brake circuit energizes the
7 Control and power releases brake coil (typically 110V or
Circuit contactor motor brake 230V AC) to release it during
motion. Brake must release
only after safety check clears.

These devices carry actual

Heavy- current for the drive motor,
Switches
duty brake, door controller, etc. The
Contactor / motor, light,
8 switches control board sends low-
Relay Blocks brake, fan,
for power voltage signals that trigger
door drive
control relays/contactors to open/close
high-voltage lines.

All critical safety devices (e.g.,

door locks, limit switches, pit
Normally Ensures buffer switch, overspeed
Safety
9 Closed operational governor contacts) are wired in
Circuit
(NC) loop safety series. Any open contact will
break the safety circuit,
preventing motion.

Typically 230V/415V AC input

converted to 24V DC and 5V
Switch- DC. Powers logic boards,
Power Converts AC
mode sensors, displays,
10 Supply Unit to DC for
power communication modules. High
(SMPS) electronics
supply reliability is essential to
prevent failure of the control
system.

11 Inspection Car top / Enables Used by technicians during

Box Interface Pit local maintenance. Includes UP,
inspection manual DOWN, STOP buttons,
box control emergency stop, light.
Sl. Descriptio
Component Function Expanded Explanation
No n

Overrides normal control logic

to allow car movement at
inspection speed under
controlled conditions.

These are mounted at top and

bottom of the shaft and on
Magnetic / Position and each floor. Used for slow-down,
Limit Switch
12 mechanica overshoot final limit, leveling, and over-
Interfaces
l switches protection travel prevention. Activated by
vanes or cams on the elevator
car.

The controller sends commands

to door operator (Wittur,
Manages Fermator, etc.) to open/close at
Door Interface
door correct time. Feedback signals
13 Controller to door
open/close indicate door status (open,
Interface drive unit
logic closed, obstructed). Some
systems use CAN bus or
dedicated IO lines.

COP: Car Operating Panel. LOP:

Landing Operating Panel.
Sends user commands (button
Reads press, emergency bell) and
COP & LOP Car and
inputs, receives signals for display
14 Communicati Landing
displays indicators (floor position,
on Panels
status direction arrows, overload,
voice announcement, etc.).
Communication is typically
serial (RS485).

Supplies 12V/24V to logic

board and emergency circuits
during a blackout. Maintains
Sealed Retains
Emergency communication, enables lift to
Lead-Acid control
15 Battery move to nearest floor, and
or Li-ion during
Backup keeps alarm/intercom
batteries power loss
functional. Some also support
ARD (Automatic Rescue
Device).

🔷 2. End-to-End Working: Step-by-Step Control Flow

🟩 A. Idle State – Monitoring

 Controller constantly reads:

 o Landing and car calls (from COP & LOPs)

o Door statuses

o Safety chain (door locks, limit switches, overspeed governor)

o Position data from encoder

🟨 B. Call Assignment & Logic

 Call request entered (e.g., user presses LOP button)

 Controller logic determines:

o Car direction

o Nearest car availability

o Load condition (optional with load sensor)

o Priority (fire mode, VIP service, etc.)

 Sets direction and target floor

🟦 C. Movement Initiation

 Ensures all safety inputs OK (safety chain closed)

 Brake is released using brake driver

 VFD (Drive) ramps up motor frequency smoothly

 Encoder feedback constantly updates position

🟪 D. Speed and Stopping Control

 VFD accelerates motor to cruising speed

 Near destination, slowdown limit switch triggers

 VFD reduces speed for precise leveling

 Final leveling is fine-tuned using encoder pulses or limit switches

🟥 E. Door Operation

 Door signal sent to door operator (via DO interface)

 Door opens

 After a time delay or signal (like obstruction-free), door closes

 Re-closing logic handled if door not closed properly

🟧 F. Emergency Handling

 Power loss: Backup battery lights emergency light, sounds buzzer

 Emergency power: Lift moves to nearest floor and opens door (ARD system)

 Overspeed or fault: Controller stops motor, engages brake, signals error

🔷 3. Peripheral Components Interfaced

Category Component Notes

Door locks, buffers, overspeed governor, pit NC-type wired in series for fail-safe
Safety
switch, limit switches logic

Encoder, position sensor (magnet or tape), For accurate car position and
Feedback
load sensor overload protection

Used for call processing and

Input COP/LOP buttons, key switches, limit switches
diagnostics

Output Display, buzzer, indicators User feedback and alerts

Door drive controller (Fermator, Wittur), Controller commands timing, delay,

Door System
interlocks and re-try logic

Connects drive, expansion IO, COPs,

Communication CANbus, RS485, Modbus
ARD, etc.

Safety tools for technician control

Inspection Tools Inspection box, OSG switch, brake test unit
during servicing

🔷 4. Typical Signal Flow Diagram (Simplified)

[Button Press] --> [IO Module] --> [CPU Logic] --> [Drive + Brake Control] --> [Motor Movement]

↓ ↓ ↓ ↓

[Encoder Feedback] ← [Controller] ← [Limit Switches / Safety Chain] ← [Mechanical Components]

🔷 5. Optional / Advanced Add-Ons

Component Use

Regenerative Drive Returns excess power to grid during down travel

Remote Monitoring Unit (IoT) For online diagnostics and performance tracking

CCTV & Voice Logger In-cabin security

Component Use

AI-Based Traffic Control Predictive destination dispatching

ARD (Auto Rescue Device) Moves lift to nearest floor on power failure

Here is a simplified and more detailed explanation of each elevator controller component from your
table, making it easier for technicians or non-specialists to understand:

🔹 1. Main Control Board (MCB) – "The Brain"

 What it is: The main printed circuit board that runs the elevator.

 What it does: It decides when and where the elevator should go, checks for safety, and talks
to all other parts.

 Simple example: Like a human brain—it takes in all information (button presses, sensor
inputs) and makes decisions (go up, open door, stop at floor).

🔹 2. Drive (VFD – Variable Frequency Drive) – "The Speed Controller"

 What it is: An electronic device that powers the lift motor.

 What it does: Changes the motor speed smoothly, allowing the elevator to start and stop
gently and save energy.

 Simple example: Like a car accelerator—it adjusts how fast the motor turns based on
instructions from the MCB.

🔹 3. Processor / PLC – "The Logic Handler"

 What it is: A small computer chip or industrial controller.

 What it does: Runs the elevator’s rules. For example: open doors only when at a floor and
stop if a safety device is open.

 Simple example: Like a traffic controller—it allows or blocks movements depending on

sensor inputs.

🔹 4. Communication Module – "The Messenger"

 What it is: A digital network link (like RS485 or CAN).

 What it does: Connects the controller to other parts like the car panel, door system, and
floor buttons.

 Simple example: Like a telephone line—it sends and receives messages between all elevator
sections.
🔹 5. IO Modules (Input/Output) – "The Signal Gate"

 What it is: Terminals where wires from switches and devices are connected.

 What it does: Collects signals from sensors and sends commands to operate doors, lights,
motors, etc.

 Simple example: Like a receptionist—it takes incoming messages (button press) and sends
instructions (turn on light).

🔹 6. Encoder / Resolver – "The Position Sensor"

 What it is: A sensor mounted on the motor or pulley.

 What it does: Tells the controller where the elevator is and how fast it’s moving.

 Simple example: Like a GPS—it tracks movement and location accurately.

🔹 7. Brake Control Circuit – "The Stopper"

 What it is: An electrical switch that controls the elevator’s brake.

 What it does: Releases the brake to allow movement, and engages it to stop safely.

 Simple example: Like a parking brake—it’s always on unless power is given to release it.

🔹 8. Contactor / Relay Blocks – "The Power Switches"

 What it is: Heavy-duty relays that control high-power devices.

 What it does: Turns the motor, brake, lights, and door systems ON/OFF as needed.

 Simple example: Like a light switch—but for high voltage systems.

🔹 9. Safety Circuit – "The Lifeline"

 What it is: A loop of safety devices all connected in a chain.

 What it does: If any safety (like door not locked) fails, the loop opens and stops the lift.

 Simple example: Like a string of fairy lights—if one breaks, the whole chain stops.

🔹 10. Power Supply Unit (SMPS) – "The Charger"

 What it is: An adapter that converts high voltage (AC) to low voltage (DC).

 What it does: Feeds 24V or 5V DC to the controller, display, and sensors.

 Simple example: Like your phone charger—it converts and supplies stable power.
🔹 11. Inspection Box – "The Manual Control Box"

 What it is: A small box on the car top or in the pit with manual controls.

 What it does: Lets technicians move the lift slowly and safely during servicing.

 Simple example: Like a service remote—it bypasses automatic control.

🔹 12. Limit Switch Interfaces – "The Floor Markers"

 What it is: Sensors installed on top and bottom of the shaft and at each floor.

 What it does: Tells the system when to slow down, stop, or prevent over-travel.

 Simple example: Like speed breakers and barriers—they ensure the car stops at the right
place.

🔹 13. Door Controller Interface – "The Door Brain"

 What it is: The connection between the elevator brain and door motor.

 What it does: Opens and closes doors at the right time and checks if doors are fully closed.

 Simple example: Like an automatic store door—it only opens when someone arrives and
closes safely.

🔹 14. COP & LOP Communication – "User Interface"

 What it is: Panels inside the car (COP) and outside on each floor (LOP).

 What it does: Lets users call the lift, select floors, and shows floor, direction, overload, etc.

 Simple example: Like pressing a button at a vending machine and watching it respond.

🔹 15. Emergency Battery Backup – "The Lifesaver"

 What it is: A backup battery pack (12V or 24V).

 What it does: Keeps the control system alive in case of power failure. Some systems allow
the car to go to the nearest floor and open doors (ARD).

 Simple example: Like a power bank—it helps the system finish its last job safely during
blackout.

Would you like this simplified explanation in a formatted Word or PDF file for your training or
technical manual?