Subscribe To
Posts
All Comments
Wednesday, February 22, 2012
Monday, February 20, 2012
CPU design for elevator control system (ECS)
CHAPTER 1
INRODUCTION
Elevators began as simple rope or chain hoists. An elevator is essentially a platform that is either pulled or pushed up by a mechanical means. A modern day elevator consists of a cab (also called a "cage" or "car") mounted on a platform within an enclosed space called a shaft or more correctly a hoist way. The first reference elevator was invented by Archimedes in 312. From some literacy source, elevator were developed as cable on a hemp rope and powered by hand or by through animals. This type of elevator was installed in the Sinai Monastery of Egypt.
In the 17th century, the very small type elevators were placed in the building of England and France.
In 1793, Lvan Kuliben created an elevator with the screw lifting mechanism for the winter place of Saint Petersburg. In 1816, an elevator was established in the main building of Sub Moscow village called Arkhamgelskoye. In the middle 1800’s, there were many types of curd elevators that carried freight. Most of them ran hydraulically. The first hydraulic elevators used a plunger below the car to raise or lower the elevator. A pump applied water pressure to a plunger, or steel column, inside a vertical cylinder. In 1852, Elisha Otis introduced the safety elevator, which prevented the fall of the cab, if the cable broke. In 1857 March 23rd, the first Otis passenger elevator was installed in New York City. The first electric elevator was built by Werner Von Siemens in 1880.
(Wikipedia, October 2011)
Design of a central processing unit (CPU) with a microcontroller model, it is however, very important to know the purpose for which the CPU will serve since CPU’s are design for variety of purposes, like the general purpose CPU as the case maybe. But for this project, the central processing unit will be design for a special purpose which is elevator control unit or lift and I will be focused on the design of a 16-bit RISC CPU that is capable of controlling a lift (elevator) and in either case, a single design pattern with a single stage pipelining will be follow using the C language. The CPU from this project will be in a ‘soft-core’ or in software form and hardware part which include all the circuit design use for Implementation and verification.
Why choose CPU?
The core of a computer is the central processing unit (CPU). A microprocessor is essentially a CPU. CPU has greatly improved over the last 20 years. The changes in the design of CPUs lead to much higher system performance. The two main aspect of CPU design that has evolved are:
1. The type of design – CISC or RISC.
2. Memory architecture.
Complex instruction set computer (CISC), this type of CPU architecture uses a large number of complicated and powerful instructions, to interface with each other. Most of the instructions require multiple clock cycle to execute. The few first generation microprocessors all had CISC design. However, RISC which stands for reduced instruction set computer, is a CPU architecture which uses a small, highly-optimized set of instructions, to do less work with each other but the execution is much faster. Most instruction only takes one clock cycle to execute.
There are 3 main blocks in computer architecture that is Memory system, Central Processing Unit (CPU) and Input & Output devices. But this project will exclude the input and output processes control which is controlled by the interrupt controller. The interrupt controller design module will be in future development plan.
1.2 Project Objectives
The attainment of great height of any project depends on the objectives set for the said project. However, the main objective of this project is to have a good plan, steps and methods in designing an actual working CPU using microcontroller and verify the design by way of implementation and show the result on seven segment display.
These are the following objectives:
1. To plan architecture of instructions set which consist of instructions op-code, source and destination operand, addressing mode of programs.
2. To design a data-path unit and control unit module of CPU using appropriate coding technique and run it with mikro C compiler
3. To design elevator circuitry with add-on display devices or component
4. To build the hardware part which include all the circuit design verification
Many modern elevators are controlled by a computer. The computers job is to process all of the relevant information about the elevator and turn the motor correct amount to move the elevator car in correct position.
In order to do this the computer needs to know at least three things, these are:
i) where people want to go
ii) where each floor is
iii) where the elevator car is
Finding out where people want to go is very easy. The buttons in the elevator car and the buttons in each floor are all wired to the computer, when anyone presses these buttons, the computer logs this request.
1.3 Scope of Project
This project is to design a 16-bit RISC CPU that is capable of manipulating user input data to control an elevator and manage data in order to process according to the output or result. Although the interrupt process includes the data transfer process between CPU, interrupt controller and I/O, the interrupt controller and I/O handshake device modules is not included in this project and is listed in future development list. This mean there is no interrupt request that cannot be handled or a real I/O process will be demonstrated. Only completed program using processor’s instructions set stored in ROM will be processed and can be monitored using software. The design and analysis of the elevator control system study about literature review of existence elevator, then design a suitable elevator controller based on the objective, continue with analysis and simulation on the sustainability and movement of the elevator system
The scope for this project is:
1. Design the CPU using C language. This project chooses micro C language rather than assembly language because it has been learnt previously and it is much easier to manipulate the C language for the project. This can save time, since more time is needed in designing the CPU. While in the meantime, the assembly language version of design will be built afterward.
2. Design the CPU’s fixed size of 16-bit instructions architecture as the RISC standard.
3. The mikro C compiler software is use for the coding.
4. The FPGA board to use is the PIC microcontroller circuit board.
5. Users are given privilege to enter request.
1.4 THESIS OVERVIEW
Chapter 1 of this thesis presents an introduction to CUP design and the Elevator control system techniques. The scope and objectives of this work, basic block diagrams, overview of 16 Bit RISC CPU and outline of this project is also presented in this thesis.
Chapter 2 of this thesis highlights the some key concept, back ground and literature reviews on both the CPU system and elevator controller system for intelligent control of an elevator.
Chapter 3 presents the methodology and brief description about the Dispatching algorithms .These algorithms reduce the average waiting time of passenger up to certain value and also reduce the power consumption of the elevator system.
Chapter 4&5 and 7 deals with analysis and the implementation of microcontroller based elevator positioning control system with (PIC16F877) Microcontroller.
1.4.1 Instruction controller
The instruction controller controls the sequence of operations within the CPU. The instruction controller contains the indicator registers which contains flags that indicate the status of data processing system. Also contained in the instruction controller is the instruction locator counter, which keeps track of the current instruction address and the instruction register and decode logic, in which the instruction being executed is held and however give details of the execution decoded.
 |
|
 |
Figure 1.1: Block diagram representation of CPU instruction
1.4.2 Program level controller
It is within this block that the register representing the priority queue are updated and check to determine if the highest priority program available to be run is actually running. This block also contains the switching program level logic (program activity determination logic).
1.5 Overview of 16-bit RISC CPU for Elevator Control
As the title, the main task of this project is to design a 16-bit RISC CPU for an elevator control using micro program. There are two units of essential modules in designing a CPU; data-path unit and control unit. A ROM and RAM handshaking modules are not yet included in this project. However, the data-path unit will include the temporary RAM module to make the system ready to be upgraded with handshaking device module. The control unit will act as the brain of a processor where all CPU’s state will be controlled conditionally (by opcode) by this unit. Or in a simple word, the control unit task is to control the data-path unit dataflow.
Figure 1.2: The block diagram below is the module to be design in this project
 |
|
Control
|
 | |||
 | |||
The block diagram explains how each unit relates to each other and the flow of data in the memory of the central processing unit (CPU). The technique of communicating via the data bus minimized the number of connection between the block shown in figure 1.2. This technique has the effect of shortening the signal line length, thus reducing propagation delays and decreasing susceptibility to noise. Each of the blocks is discussed as shown bellow in the following.
Figure 1.3 below is the pipeline for this CPU system
 | |
 |
Figure 1.3 Sequence of events in processor (single pipelining)
This project is to design a CPU that is capable in manipulating data in various methods with conditioning processes. That mean, a register of Processes Status (CCR) is essential. The CPU must have Program Counter and Stack architecture involving instructions like Jump (JMP), Branch (BRA), Return (RET) from sub-module & subroutine.
This project will follow a guideline of designing, ‘analyze & synthesis’ and simulate every single element of the system analytically using microC software. This is to make it easier to repair the design if any error is encountered in the design.
For example, in designing a storage element of common registers (D-Flip Flop) sub-module, designer will follow the guideline as mentioned above before proceed in merging all the sub-modules in data-path unit top level module. Below is the list of possible element in CPU system:
1.5.1 Data-path Unit
This unit will include below sub-modules:
1. Arithmetic logic unit (ALU)
2. Accumulator registers (AC)
3. Program counters (PC)
4. Instruction registers (IR)
5. Stack pointer (SP)
6. Condition code registers (CCR)
7. Manipulated register (R)
8. Random access memory (RAM).
1.5.2 Control Unit
This unit will be designed as a Finite State Machine (FSM), and this unit will control and manipulate all data and system’s behaviour as the compiler’s written program.
Then, after all the modules have been created and designed as a working design, both units (data-path and control) will be analyzed again, synthesis and simulate whether there is any Syntax or Symantec error. This is much faster than ignoring the preset guideline where the designer will obviously confuse which part of the system is at error when the system’s design is getting bigger and wider. Then when the CPU’s design is working properly in the test simulation, the design will be downloaded into the PIC microcontroller. This is to verify the program written using the designed instructions in FPGA. For this project, the hardware circuit component is used to implement the design in real environment.
 |
 | |||||
| |||||
 | |||||
Figure 1.4: The block diagram of control signal.
The system clock is an accurate, fast, electronic timer which generates pulse to synchronize all the chips inside the computer system, whereas the memory data register stores the content of the last “word” read to or write from main memory.
CHAPTER 2
LITERATURE REVIEW
2.1 Literature Review
This section highlights the importance of using a working CPU model to show some theory and simplified information regarding the project. It also describes the investigation of existing CPU models that were considered for hardware implementation, and the results of a research. The materials in this section are collect for the basic information and knowledge about the project and as a guide before starting any actual design for the project.
2.2.1 Central Processing Unit (CPU)
Microprocessor is a CPU (Central Processing Unit) that is build into a single chip semiconductor which is a general-purpose device, suitable to perform many kinds of applications or operations. When the microprocessor is combined with input or output and memory devices, it is called microcomputer. The choice of these devices that are combined depends on the specific application. For example, most personal computers contain a keyboard and monitor as standard input and output devices. The major difference of a microcontroller compared to a microprocessor and microcomputer is that microcontroller consists of central processing unit (CPU), memory devices (ROM and RAM), input and output ports and timer embedded into a single chip
. They also have many on-chip facilities such as serial port, counters, analogue to digital converter and interrupt control so that they can be interfaced with hardware and control functions of many kinds of application. It is ideal for many applications in which cost and space are critical. Microcontroller has a wide range of applications in many control-oriented activities. For example, they are used as engine controllers in automobiles and as exposure and focus controllers in cameras as well as they are used in a lift control system. The difference between microprocessor and microcontroller is shown in figure 2.1
2.2.2 Instruction Set Architecture
CPU’s instructions set architecture (ISA) is one of the most important parts in designing CPU. There is two important points to be abided in designing this arguably design:
1. Instruction set should have all the functions and data manipulation type to enable variety of programs.
2. But at the same time some instructions do not almost do the same thing. This is to avoid redundant instruction set and lowering the cost in manufacturing the designs hardware.
Contain a division of op-codes and operands; an instruction area design is the most important part when designing a CPU. The capability of varying the pattern of operand (addressing mode), instruction’s capabilities (i.e.: branching to multi-module), supported processes (i.e.: arithmetic) which may saved assembler time in designing a program. This also may lead to a difference more successful result. The ISA specifies the choice of programming model, registers number, and addressing modes (method of accessing data).
The ISA includes:
1. Instruction set format
2. Instruction set variation (number)
3. Machine’s memory
4. Programmers accessible registers
5. Compulsory registers (IR, PC, SP, CCR, MAR, MDR)
6. Machine computing for arithmetic and others type of data manipulation (ALU)
Instruction set formats
The purpose of an instruction is to specify both an operation to be carried out by a CPU or other processor and the set of operands or data to be used in the operation. The operands include the input data or arguments of the operation and the result that are produced.
John P. Hayes(computer architecture and organisation)third edition.
2.2.3 What and why CU?
CU stands for ‘control unit’. As described in the last chapter, control unit is acting like a brain of a CPU. It built as a Finite State Machine as the machine can only accomplish one task at a time. It controls all the connection in the data-path unit. Which storage (i.e.: DFF) to be enabled, which is not, which subunit (i.e.: ALU) to be enabled and which are not. Figure 2.1 below shows the Mealy Finite State Machine block diagram.
Figure 2.1 Functional block diagram of Mealy FSM
2.2.4 What and why DU?
DU stands for ‘data-path unit’. This unit usually contains several essential elements such common data/address registers monitored registers, status registers, counter, pointer, arithmetic logic unit (ALU) and ROM, RAM and Interrupt handshaking component. All this components is connected together through several busses such as multiplexer.
How does it work?
The Control & Data-path unit is coexists in a CPU. Both of this unit needs to work together in order a system can operates in a synchronous rhythm (clock). For storage element, D Flip flop (DFF) commonly used (as accessible or inaccessible registers). The edge triggered behaviour of this element enables synchronization in a digital system. It also has the higher priority enabler input which enables the element to hold the last input given or overwrite the output with the latest input. This pin usually called as the ‘load’ or ‘enable’ pin. This is the most important behaviour of multiplexers and DFF which allowing the Control unit (FSM) to construct a line of circuit connection in the Data-path unit to accomplish certain task sequentially. This is why this kind of circuit is called as a ‘sequential circuit’. Figure 2.2 below shows the relationship between data-path unit, control unit and interrupt controller.
Figure 2.2The relationship between data-path unit, control unit and interrupt controller
Referring to Figure 2.2, control unit only needs to know the current op-code being ran by the system. And in several clock cycles the data-path unit will be given a control vector in sequent to manage and process the several data to produce desired result.
Commonly for a CPU, a pipeline of processes is used as shown in Figure 2.3. For this project, only single stage pipeline architecture is built. Somehow a block called "control logic" sets up the ALU for the correct operation and loads all of the correct registers at the proper time. But, students in Electronics Engineering Technology want to know how this is accomplished. By building a simple demonstration CPU that actually works, both levels of understanding can be satisfied. The block diagram can be used to learn the basic principles, and the detailed design of the functional CPU can tie the functional blocks back to actual circuits.
2.2.5 Initial CPU Model Specifications
Two loosely defined CPU specifications were proposed for this project. The CPU had to be powerful enough to illustrate most of the common features in modern CPUs. It would also have to be simple enough to implement at the IC level within a short amount of time. Although some of these specifications were later modified or discarded, they were used to evaluate the existing CPU models and formed the design basis for the CPU in this project.
1. The CPU should be simple enough to be implemented with a "small" number of ICs (about 2) from the microcontroller family.
2. The control unit should support conditional branching.
3. Include a hardware interrupt.
4. Use an 8-bit data-path and 8-bit address bus to reduce complexity.
5. Incorporate a "small" number of internal data registers (about 3) to demonstrate how they function.
6. The ALU should implement an assortment of arithmetic and logical operations, in order to make the instruction set as complete as possible.
7. The instruction set should include "several" common addressing modes at least 3.
8. Include instructions that are usually found in real CPUs.
9. Implement simple stack operations.
10. No pipelining or other parallel processing techniques should be attempted. They would detract from the simple operation required for easy understanding, and would certainly conflict with goal # 1.
2.2.6 Alternative Computer Models
This section briefly describes two different CPU models that have been developed for use in college-level computer courses. They are identified in this report by the name of their respective developers. Each one will be compared to the design goals in the previous section. The features, and advantages and disadvantages of each will be identified. The suitability of each model for hardware implementation will be discussed.
2.2.7 Lynn CPU
This CPU model was developed by Doug Lynn for use in his EE 340 and EE 441 courses at the University of Idaho (Lynn, 1996). A diagram of the Lynn CPU is shown in Figure 2.3.
Figure 2.3: Functional Block Diagram of Lynn CPU (Lynn, 1996, EE 441 Handout)
Hardware Features
CPU Architecture: Accumulator-Based CPU
Data Bits: 8
Address Bits: 5
Internal Registers: 1 Accumulator (A)
Flags: Zero (Z)
Carry (C)
Negative (N)
Overflow (V)
Instruction Set
Input/Output: None -- --
Program Control: BRU address Direct PC <--address
BRZ address Direct If Z=1: PC <-- address
Data Transfer: LOAD address Direct A <-- MEM(address)
STORE address Direct MEM(address) <-- A
Arithmetic: ADD address Direct A <-- A + MEM(address)
SUB address Direct A <-- A - MEM(address)
Logical: SHR Register A <-- 0 ## [A]7..1
Evaluation : Estimated Number of ICs: 20 (12 + State Machine + Memory)
Conditional Branching?: Yes
Hardware Interrupt?: No
8-Bit Data Bus?: Yes
8-Bit Address Bus?: No (5 bits)
Number of Registers: 1 (Accumulator)
# of ALU Operations: 3
# of Addressing Modes: 2
Stack Operations?: No
Pipelining?: No
Decision
The Lynn CPU would be easy enough to build, but it does not have many features common to contemporary CPUs. It instruction set is too limited and does not implement all of the hardware features. Different addressing modes cannot be demonstrated effectively. The available memory is too small to run an actual program. This CPU model would not be an acceptable candidate for implementation
2.2.8 Streib CPU
William Streib presents this model in his book (Streib, 1997). See the block diagram in Figure 2.4.
Figure 2.4: Functional Block Diagram of Streib CPU (Streib, 1997, p. 323).
Hardware Features
CPU Architecture: Accumulator-Based
Data Bits: 8
Address Bits: 16
Internal Registers: 1 Accumulator (A)
2 General Purpose Registers (B, C)
2 Special Purpose Registers (H, L)
Flag: Zero (Z)
Instruction Set
Input/Output: INPUT address Direct A <-- PORT(address)
Program Control: JUMP address Direct PC <-- address
COND JUMP address Direct If Z = 0: JUMP address
Data Transfer: LOAD A address Direct A <-- MEM(address)
MOVE A, B Register A <-- B
Arithmetic: None -- --
Logical: AND data Immediate A <-- A AND data
Evaluation
Estimated Number of ICs: 24 (14 + Decoder + Control & Timing + Memory)
Conditional Branching?: Yes
Hardware Interrupt?: No
8-Bit Data Bus?: Yes
8-Bit Address Bus?: No (16 bits)
Number of Registers: 5 (1 Accumulator + 2 GPs + 2 SPs)
# of ALU Operations: 1
# of Addressing Modes: 3
Stack Operations?: No
Pipelining?: No
Decision
The Streib CPU would be only slightly more difficult to build than the Lynn CPU. There is ample memory space. It has many hardware features common to contemporary CPUs, but its instruction set does not implement most of them. The instruction set uses three different addressing modes, but is very weak functionally especially the available ALU operations. This CPU model would not be an acceptable candidate for implementation
2.3.1 Some Words for Processor
ALU - Perform mathematical and logical operations
ASIC - Application specific integrated circuit
CAD - Computer aided design
CCR - Condition code register / status register
CISC - Complex instruction set computer
FPGA - Field-programmable gate arrays
IR - Instruction register
MAR - Memory address register
MDR - Memory data register
OPCODE - An identical machine code of binary for a specific task and an essential part of instruction architecture
OPERAND - Instruction set arguments, commonly consist of a pair of source and destination
PC - Program counter
RISC - Reduced instruction set computer
RTL - Register transfer level
SP - Stack pointer
2.3.2 Instruction pipelining
An instruction pipeline is a technique used in the design of computers and other digital electronic devices to increase their instruction throughput (the number of instructions that can be executed in a reasonable amount of time). Pipelining does not reduce the time it takes to complete an instruction; it increases the number of instructions that can be processed at once, thus reducing the delay between completed instructions. The fundamental idea of pipelining was to split the processing of a computer instruction into a series of independent steps, with storage at the end of each step. This allows the computer's control circuitry to issue instructions at the processing rate of the slowest step, which is much faster than the time needed to perform all steps at once. The term pipeline refers to the fact that each step is carrying data at once ‘like water’, and each step is connected to the next ‘like the links of a pipe’. A typical 4 stage instruction pipeline is as shown below.
Figure 2.5 the generic 4-stage instruction pipeline; the coloured boxes represent instruction independent of each other
Most modern CPUs are driven by a clock. The CPU consists internally of logic circuits and registers (flip-flops). When the clock signal arrives, the flip flops take their new value and the logic then requires a period of time to decode the new values. Then the next clock pulse arrives and the flip flops again take their new values, and so on. By breaking the logic into smaller pieces and inserting flip flops between the pieces of logic, the delay before the logic gives valid outputs is reduced. In this way the clock period can be reduced. For example, the classic RISC pipeline is broken into five stages with a set of flip flops between each stage.
2.3.3 ADVANTAGES AND DISADVANTAGES OF PIPELINING
Advantages of Pipelining:
1. The cycle time of the processor is reduced, thus increasing instruction issue-rate in most cases.
2. Some combinational circuits such as adders or multipliers can be made faster by adding more circuitry. If pipelining is used instead, it can save circuitry vs. a more complex combinational circuit.
Disadvantages of Pipelining:
1. A non-pipelined processor executes only a single instruction at a time. This prevents branch delays (in effect, every branch is delayed) and problems with serial instructions being executed concurrently. Consequently the design is simpler and cheaper to manufacture.
2. The instruction latency in a non-pipelined processor is slightly lower than in a pipelined equivalent. This is because extra flip-flops must be added to the data path of a pipelined processor.
3. A non-pipelined processor will have a stable instruction bandwidth. The performance of a pipelined processor is much harder to predict and may vary more widely between different programs.
2.4.1: History of Elevator
An elevator system is a vertical transport vehicle that efficiently moves people or goods between floors of a building. They are generally powered by electric motors. The most popular elevator is the rope elevator. In the rope elevator, the car is raised and lowered by transaction with steel rope. Elevators also have electromagnetic brakes that engage, when the car comes to a stop. The electromagnetic actually keeps the brakes in the open position. Instead of closing them with the design, the brakes will automatically clamp shut if the elevator loses power. Elevators also have automatic braking systems near the top and the bottom of the elevator shaft.
During the middle ages, the elevator operated by animal and human power or by water-driven mechanisms. The elevator as we know it today was first developed during the 1800s and relied on steam or hydraulic plungers for lifting capability. In the latter application, the cab was affixed to a hollow plunger that lowered into an underground cylinder. Liquid, most commonly water, was injected into the cylinder to create pressure and make the plunger elevate the cab, which would simply lower by gravity as the water was removed. Valves governing the water flow were manipulated by passengers using ropes running through the cab, a system later enhanced with the incorporation of lever controls and pilot valves to regulate cab speed. The granddaddy of today's traction elevators first appeared during the 19th century in the United Kingdom, a lift using a rope running through a pulley and a counterweight tracking along the shaft wall.
(Elevator Info, 1992)
In the 1800s, with the advent of electricity, the electric motor was integrated into elevator technology by German inventor Werner von Siemens. With the motor mounted at the bottom of the cab, this design employed a gearing scheme to climb shaft walls fitted with racks. By 1903, this design had evolved into the gearless traction electric elevator, allowing hundred-plus story buildings to become possible and forever changing the urban landscape. Multi-speed motors replaced the original single-speed models to help with landing-levelling and smoother overall operation. Electromagnet technology replaced manual rope-driven switching and braking. Besides, Push-button controls and various complex signal systems modernized the elevator even further. Safety improvements have been continual, including a notable development by Charles Otis.
(Charles Otis, 1996)
Today, there are intricate governors and switching schemes to carefully control cab speeds in any situation. Buttons have been giving way to keypads. Virtually all commercial elevators operate automatically and the computer age has brought the microchip-based capability to operate vast banks of elevators with precise scheduling, maximized efficiency and extreme safety. Elevators have become a medium of architectural expression as compelling as the buildings, in which they are installed, and new technologies and designs regularly allow the human specify new system. (Elevator Info, 1992)
2.4.2 TYPES OF ELEVATOR IN EXISTENCE
Currently, there are two types of elevators, hydraulic and traction or roped. The hydraulic elevator consists of a cab attached to the top of a hydraulic jack similar to a jack used for a car lift in a service station. The hydraulic jack assembly normally extends below the lowest floor and is operated by a hydraulic pump and reservoir, both of which are usually located in a separate room adjacent to the elevator shaft. Hydraulic elevators are the type generally used in single-family residences. The second type is the roped elevator. This is the system that is most commonly associated with elevators. The roped system consists of a cable that is connected to the top of the cab and is operated by an electric motor located in a penthouse above the elevator shaft.
2.4.3 ROPED ELEVATOR
The basic mechanism of roped elevator dynamic system with respective components is shown in figure2.1. The elevator consists of four major inertial elements which are the drive sheave; elevator car; counter weight and compensation sheave.
Each of the inertial components connected to each other with rope segments whose 6 length vary as the elevator car move up and down the hoist way. The mass of the car can vary depending on the number of passenger.
Figure2.6: Schematic of basic mechanism of the elevator system (Young Man Cho and Rajesh Rajamani, 2001).
The structure dynamics of hoist-way ropes using mass approximation to get the force transmission delay in each of four difference rope segments. Each of the ropes segment are consist of difference type because the ropes have difference parameter values for stiffness, mass, and damping. In addition, stiffness and damping value of dampers connected to an inertial ground for drive sheave, compensation sheave rotation, and translation, counterweight, and elevator cab are also included in the model.
2.4.4 The Velocity Control of Roped Elevator
The roped elevator control input given by the torque to drive the sheave motor and payload. The velocity control system also depends on the behaviour of the first two modes at the bottom for the hoist-way with the position of the elevator car. This could be determined by random input test at difference point at hoist way. The behaviour of the first rope mode is illustrated in figure 2.7 for transfer function between the velocities of the drive sheave to the velocity of the car. The stiffness and damping are absolute and real values of the poles at the corresponding frequency.
Figure 2.7 graphical behaviour of the first rope mode
The variations of the first rope mode observe in drive sheave. Car velocity transfer function. The systems get more stable as the elevator car approaches the top of the hoist-way. This controller based on the dynamics at the bottom of the hoist way, the system require for non linear closed loop stability. Then notice that the behaviour can be approximate well by using height of 60 floors corresponding to the height of 200m.
The elevator system from the central view point also provides two sensor measurements, car position and drive sheave velocity, and the single control in the form of torque actuation through a motor to a drive sheave. To evaluate the performance for the elevator vertical ride, a set of standardized test is often used in practice.
Saligrama. R. Venkatesh, Young Man Cho and Jongwon Kim are concern about re-levelling error and vertical ride quality.
Re-levelling error is a measure of the elevator system response to increase or decrease of payload in the elevator car. The test required that the elevator car be regulated to within 6mm of the target floor position quickly in response to any pay load ranging from 0% to 100% capacity. A smooth profile as shown in the figure 2.3 is typically used as basis for measurement re-levelling. This profile simulates the effect of increasing the payload from 10% to 50% in 15 seconds.
2.4.5 HYDRAULIC ELEVATOR
The hydraulic elevator consist of a control schemes to make sure the passenger feel comfortable using this elevator. The control scheme of hydraulic elevator consist of three schemes control steps which is the load pressure compensation step, the velocity tracking control step and the destination position control step. The load pressure compensation step reduces the joint of the car that may produce an uncomfortable ride for passenger. The velocity tracking control makes the car follow a reference velocity profile that help the passenger feel comfortable during the movement of elevator. The third control scheme the destination position control reduces the position error which may exist after the velocity tracking control at the target position.
The hydraulic vector system was divided into two parts, a mechanical part that includes car, rope, and pulleys, and a hydraulic part that includes the cylinder, logic valve, hydraulic power unit, and pipes as show in the figure below. There is a hydraulic pump built in the hydraulic power unit connected directly to an electric motor to generate fluid power and controls the velocity of the car. A smooth transportation of car depends on smooth movement of the cylinder generate by hydraulic power. Every each of the part is very importance to transport the passenger to the destination position.
Figure 2.8: hydraulic elevator (Chang-Sei Kim, Keum-Shik and Moon-Ki Kim)
2.4.6 Control Speed System of the Hydraulic Elevator
The hydraulic elevator was improved with the rapid development of modern science and technology. Most of hydraulic systems are used electro hydraulic proportional technology to analyze an ideal operating state. In recent years the designer gradually adopted to design high technology of the hydraulic elevator which makes hydraulic elevator more steady with pressure loads, dynamic response in velocity tracking and stable when reach the destination position. The hydraulic elevator is based on the technique cores of variable voltage variable frequency (VVVF) were developed with development of computer control show in the figure 2.9. Perfect control of the VVVF hydraulic elevator is realized by combining the control of the motor revolutions with a flow rate transducer or velocity transducer of excellent performance.
The control systems of the VVVF hydraulic elevator consist of two parts. The first is upward running system which consists of VVVF motor and the constant delivery pump. The second is the downward running system which consists of hydraulic motor, electric motor, and energy feedback.
Figure 2.9: Block diagram of VVVF hydraulic elevator system (Yang Huayong , Yang Jian , and Xu Bing,2004).
The VVVF hydraulic elevator is moving upward when the elevator begin to run up, the upward signal is send by the computer controller and its transferred into the inverter by D/A according to the input signal, the inverter drive the motor, when the output pressure of the pump is larger than payload, the hydraulic oil opens a one-way valve and flow into the cylinder to make the piston move upward. Meanwhile, the VVVF hydraulic elevator is moving downward when the elevator begins to run down, the pressure pre-balance is controlled first at both side of the one way valve. Once the pressure pre-balance controller has finished, the hydraulic elevator starts to descend. The control signal given by the computer controller will switch electric motor to run from upward direction to a reverse direction and the electric motor begins to generate electricity at that time. During entire downward process, the computer controlled continuously calibrates control signals according to the ideal curve of velocity and practical running. The practical running curve of the elevator always coincides with the ideal running curve.
CHAPTER 3
PROJECT METHODOLGY
3.1 Introduction
Project methodology covers and contains vital things including the procedures, methods, in which ideas & information were gathered from the beginning of the project till it completion. However, the main goal of this project is to design a working CPU for an elevator system using PIC microcontroller and verify the design by implementing the hardware circuitry. Peripheral interface controller (PIC) plays a significant important function in this project to control its overall operation. These operations include instruction for elevator up/down movement and door open/close. Input from calling button and level sensors (limit switch) will feed into the PIC input module. The input will be send to central processing unit (CPU) inside the PIC to process as required by instruction program. The instruction program will then determine the operation sequence. After being process by the CPU, it will send the signal as the output to be feed to actuator (motor).
3.1.1 Summary
By establishing some requirement for the CPU and elevator system in mind, however in attempting to finally design and implement a simple architecture without sacrificing the important and basic issues in such design. For example we need first to address the following issues: word length, memory size, and registers. These can also be restated or modified without in another design once the methodology is adhered to. Since a previously published design is adopted, the first two steps in our methodology would be to define our basic CPU:
1. 16-bit data word length and 12-bit memory address and so on. The word length size can address double precision data more readily than 8-bit designs, yet it adds little overhead in our methodology. The memory size will not be too prohibitive for hardware implementation. My choice for the target hardware is PIC microcontroller as single device. The memory size can be increased if a newer device is selected. The hardware components will consist of ; A memory unit with 2k words of 16-bits each, Ten registers, Control Logic Unit, Arithmetic Logic Unit (ALU), Two decoders: a 3x8 operation decoder and a 4x16 timing decoder, A 16-bit multiplexer based common bus.
3.1.2 The overall project methodology
|
 |
Figure 3.1 The overall project methodology
3.1.3 Research and Study Methodology
In the preliminary research and study stage, a level of criteria is set as a guideline in preparing the material for the project like in the Figure 3.2 below.
 |
Figure 3.1.2 Study methodology
3.2 Design Methodology
There are two basic types of digital design methodologies:
1. Top-Down design methodology
2. Bottom-Up design methodology
In the top-down methodology, the design starts from the top with the assumption that resources are globally accessible by each subcomponent of the system, as in the centralized case. The concept of Top-Down design is in modularization, in which a large scale, complex task is broken down into a hierarchy of modules, from the general and conceptual at the top, to the specific and detail at the bottom. The top-down approach illustrated in Figure 3.3.2a below, decomposes the system into subsystem that they are decomposed again into simpler subsystem, until a level is reached at which the subsystems can be realized directly with available module.
Figure 3.2 conceptual representations of the two design methodologies.
Figure 3.2.1 Hierarchy implementation: (a) Top-down approach; (b) Bottom-up approach.
In the bottom-up methodology, on the other hand, the rules of agent interactions are design typically in an ad hoc manner. Although recent works has attempted to formalize the design process for some applications, in systems designed starting from the bottom. The global state of all the components is assumed to be impossible to obtain, and the desired collective behaviour is said to emerge from interactions among individual agents and between the agents and the environment. The Bottom-Up approach, illustrated in Figure 3.3.2b above, connects available modules to form subsystem, and these subsystems are connected to other subsystem until the required functional specification is fulfilled. This project applies the bottom up approach method.
3.3 CPU DESIGN
During the design phase, in a reasonable period of time to begin the CPU design, a 16-bit of instruction format is chosen. This happens after taking into consideration the number of physical and system operations needs and program’s operation specifications to be design to make the system capable of supporting huge amount of data manipulation and also to ease the programming of the system. Below is the design flow of the CPU.
 |
Figure 3.3 CPU design methodologies.
The most appropriate way to approach any project as large as a CPU for an elevator control, the process design is to break it up into simple steps.
To design this project:
1. Read project requirements.
2. Discussed what we knew, and what we needed to know.
3. Decide on the implementation we wanted to work with.
4. Discuss the modifications of the implementation we want to implement
5. Clearly define the goals of the project.
6. Develop a timetable and schedule to work with.
7. Break the large CPU into individual component modules that can be coded separately and assign these modules timeline for completion.
8. Build individual modules.
9. Perform simple debugging of individual modules.
10. Integrate all these individual modules into one CPU.
11. Test the functionality of the CPU.
12. Debug, debug, and more debugging.
13. Discuss and add more features.
14. Document the project and the design process.
3.4 ELEVATOR DESIGN METHODOLOGY
This paper will describe the modelling process of an Elevator Control (EC) using microcontroller and define all the input/output in C language.
The proposed system will act as a set of elevators typically found in a high-rise building. The EC will be a distributed embedded system, consisting of a set of communicating Elevator Control Units (ECU) implemented as a System-on-Chip (SOC). My design will be described at roughly the first three levels illustrated in Figure 3.4. In addition, the ECS will be modelled as a set of Elevator Control Unit (ECU), each ECU representing a subcomponent of the system. A hierarchy of subcomponents will be modelled and validated individually.
Requirement Elevator constraints
 |
Pure functional untimed
 |
Transaction level
Estimated timing
 |
Bus functional timing accurate
 |
Structure timing
Figure 3.4 Abstraction level in elevator system design
3.5 System Integration
System integration issues can be simplified if a hierarchical structure is implemented. The modularity of these models also makes adding features easier. In the (ECS), multiple units can be instantiated.
This requires the (ECU) structures to include ports for identification purposes. To support this, the port can be declared with a hardwired identification number. Furthermore, a door panel will also need an identifying door number. This can be modelled by adding yet another port dedicated to identify the door ID. In the (ECS) two main hierarchical components are grouped, the door and car units. A door unit consists of a panel, display and a door. Similarly, a car unit is composed of these units as well. These structures are illustrated in figure 3.5. For clarity, the ports unique to each structure have been omitted, showing only the identification and communication port.
Figure 3.5: The Floor and Car Unit Hierarchical Structure.
Hierarchical modelling can be applied further in the system design. The car unit and door unit can be subcomponents of a new structure in a shaft unit. In this module, the motor control unit is also integrated within the shaft unit. An EC system can be modelled by initiating a shaft unit and a main controller. Multiple elevators can be declared by instantiating multiple shaft units. Therefore by implementing a hierarchical model, a generic model is designed.
3.6 WORKBREAK DOWN STRUCTURE (WBS)
PROJECT ACTIVITY 1.1.1
STEP1.1 ACTIVITY 1.1.2
ACTIVITY 1.1.3
ACTIVITY 1.2.1
PHASE 1 STEP 1.2 ACTIVITY 1.2.2
ACTIVITY 1.2.3
ACTIVITY 1.3.1
STEP 1.3 ACTIVITY 1.3.2
ACTIVITY 1.3.3
ACTIVITY 2.1.1
STEP 2.1 ACTIVITY 2.1.2
ACTIVITY 2.1.3
PHASE 2 STEP 2.2 ACTIVITY 2.2.1
ACTIVITY 2.2.2
ACTIVITY 2.2.3
ACTIVITY 2.3.1
STEP 2.3 ACTIVITY 2.3.2
ACTIVITY 2.3.3
ACTIVITY 3.1.1
STEP 3.1 ACTIVITY 3.1.2
ACTIVITY 3.1.3
ACTIVITY 3.2.1
PHASE 3 STEP 3.2 ACTIVITY 3.2.2
ACTIVITY 3.2.3
ACTIVITY 3.3.1
STEP 3.3 ACTIVITY 3.3.2
SACTIVITY 3.3.3
Figure 3.6 work breakdown structure
3.7 MILESTONE
This is use to provide a control point or a series of indicators regarding project progress to date and achievements or goals yet to be reached. It gives the management a clear view of specific level of accomplishment. The milestone list affords team members and engineers the same information, but more as a gauge of their own level of achievement. The more significant the milestone associated with accomplishment, the greater its potentials to inspire performance.
LIST OF MILESTONE
| PHASES/STEPS | ACTIVITIES |
| STEP 1.1 | REQUIREMENT ANALYSIS AND DEFINITION |
| STEP 1.2 | SYSTEM DESIGN OF CPU AND ELEVATOR |
| STEP 1.3 | PROGRAM DESIGN |
| STEP 2.1 | WRITING THE PROGRAM / PROGRAM IMPLEMENTATION |
| STEP 2.2 | UNIT TESTING |
| STEP 2.3 | INTEGRATION TESTING |
| STEP 3.1 | SYSTEM TESTING |
| STEP 3.2 | COUPLING |
| STEP 3.3 | FINISH |
Table 1.1 List of mile stone
3.8 ACTIVITY GRAPH: An activity graph depicts the dependencies among activities and milestones. An activity starting from a milestone can only begin after all activities ending at that milestone have been completed. For instance, activity 1.1.3 can only begin after activities 1.1.1 and 1.1.2 have been completed.
| PHASES | ACTIVITIES RELATED TO STEPS |
| Phase 1, step 1.1 |
|
| Activity 1.1.1 | Prepare for system requirement analysis |
| Activity 1.1.2 | Define logical data model / process model |
| Activity 1.1.3 | Produce functional specification |
| Phase 1, step 1.2 |
|
| Activity 1.2.1 | Define technical architecture / system standard |
| Activity 1.2.2 | Component design / prototype system component |
| Activity 1.2.3 | Testing of component compatibility |
| Phase 1, step 1.3 |
|
| Activity 1.3.1 | Standard program design |
| Activity 1.3.2 | Design program interface |
| Activity 1.3.3 | Design reliable program unit |
| Phase 2, step 2.1 |
|
| Activity 2.1.1 | Study the nature of code to be written(Pascal) |
| Activity 2.1.2 | Study language use by the code(C language). |
| Activity 2.1.3 | Implement the code |
| Phase 2, step 2.2 |
|
| Activity 2.2.1 | Testing each unit and subset of the project |
| Activity 2.2.2 | Study problem if occur |
| Activity 2.2.3 | Provide solution |
| Phase 2, step 2.3 |
|
| Activity 2.3.1 | Testing of parts compatibility |
| Activity 2.3.2 | Provide reliable compatibility |
| Activity 2.3.3 | Open face testing |
| Phase 3, step 3.1 |
|
| Activity 3.1.1 | First testing and observation |
| Activity 3.1.2 | Second testing |
| Activity 3.1.3 | Final testing |
| Phase 3, step 3.2 |
|
| Activity 3.2.1 | Etching of circuit borad |
| Activity 3.2.2 | Drilling of holes |
| Activity 3.2.3 | Soldering of circuit component |
| Phase 3, step 3.3 |
|
Table 1.2 activity graph
3.9 ACTIVITY AND TIME ESTIMATES
| ACTIVITIES | TIME ESTIMATES Real Time | SLACK TIME ( time before next activity begin) |
| step 1.1 | | |
| Activity 1.1.1 | 4 days | 2 days |
| Activity 1.1.2 | 12 days | 1 days |
| Activity 1.1.3 | 6 days | 3 days |
| step 1.2 | | |
| Activity 1.2.1 | 11 days | 1 day |
| Activity 1.2.2 | 9 days | 2 days |
| Activity 1.2.3 | 7 days | 2 days |
| step 1.3 | | |
| Activity 1.3.1 | 6 days | 3 days |
| Activity 1.3.2 | 5 days | 1 day |
| Activity 1.3.3 | 10 days | 2 days |
| step 2.1 | | |
| Activity 2.1.1 | 10 days | 3 days |
| Activity 2.1.2 | 9 days | 2 days |
| Activity 2.1.3 | 5 days | 1 day |
| step 2.2 | | |
| Activity 2.2.1 | 8 days | 2 days |
| Activity 2.2.2 | 10 days | 1 day |
| Activity 2.2.3 | 5 days | 2 days |
| step 2.3 | | |
| Activity 2.3.1 | 7 days | 1day |
| Activity 2.3.2 | 12 days | 1 day |
| Activity 2.3.3 | 9 days | 2 days |
| step 3.1 | | |
| Activity 3.1.1 | 14 days | 2 days |
| Activity 3.1.2 | 10 days | 3 days |
| Activity 3.1.3 | 7 days | 2 days |
| step 3.2 | | |
| Activity 3.2.1 | 9 days | 1 day |
| Activity 3.2.2 | 8 days | 1 day |
| Activity 3.2.3 | 7 days | 2 days |
| step 3.3 | | |
| Activity 3.3.1 | 4 days | 1 days |
| Activity 3.3.2 | 9 days | 3 days |
| Activity 3.3.3 | 1 day | |
Table 1.3 activities and time estimate
CHAPTER 4
ANALYSIS
4.1 PROBLEM INEXISTING SYSTEM
Overheating
A common problem with elevator installations is the overheating of the drive and control system. In electrical traction elevators, the equipment is typically located in a penthouse above the building’s roof. The penthouse is seldom heated or cooled. Ventilation is provided by louvers mounted on the walls of the penthouse, near the roof of the building. With this type of installation, the temperature in the mechanical room is allowed to float with changes in the outside air temperature. But since the ventilation is drawn from near the roof’s surface, the temperature in the equipment room can easily exceed 100 degrees on a warm, sunny day. As the temperature increases, so does the chance of breakdowns caused by overheating.
Attempting to cool the elevator equipment with outdoor air also introduces other causes of frequent breakdowns: dirt and humidity. Outside ventilation air is rarely filtered. It carries with it large volumes of dust and dirt that are deposited on equipment. Dirt can interfere with the contacts in the control system and can act as a layer of insulation, further increasing the chances of overheating. Humidity accelerates the corrosion of contacts.
Elevator algorithm:
1. Serve the entire request in one direction and then reverse the direction.
2. Shortest seek first.
3. Serve the request closest to the present floor.
4. First come first serve, serve requests as they arrive.
The justification for using elevator algorithm.
1. Disadvantages of shortest seek first.
Irrespective of the time at which request is placed, it only caters to the request
closest to the present floor. If someone places a request for the last floor
there are lots of other requests for nearby floor as it is a busy place
also if they keep coming then that person's request is not at all catered to for a long time. Why?
2. Disadvantages of first come first serve basis.
Inefficient as far as power requirements are concerned and more time will be taken on an average to reach the required destination.
The elevator algorithm takes care of these two shortcomings by catering to the request in it direction then reverses direction when it reaches top floor or there are no more request for the upper floors; the same is repeated for the downward direction.
4.2 PROBLEM STATEMENT
Long Wait Times
Long wait times are an inconvenience for building occupants, and they can also be a warning that the elevator control system is developing problems.
Long wait times and slow performance may be caused by a malfunction as simple as a defective relay, or problems may be caused by the age and overall condition of the elevator. While repairs can improve performance in some cases, elevators that use old mechanical relay control systems may simply need a new control system. Mechanical relay-based systems are slow by today’s standards, and little can be done to improve their performance. Upgrading to a new microprocessor-based control system reduces average wait time by 60 percent. When coupled with a new drive system, the speed of the elevator can be increased by an average of 50 percent.
The elevator button problem: User interface design is hard. It is hard because people perceive apparently simple things differently. For example, take a look at this interface to an elevator:
Figure 4.1 interface to an elevator
Now imagine the following situation. You are on the third floor of this building and you wish to go to the tenth. The elevator is on the fifth floor and there is an indicator that tells you where it is. Which button do you press?
Most people probably say: "press up" since they want to go up. Not long ago I watched someone do the opposite and questioned them about their behaviour. They said: "well the elevator is on the fifth floor and I am on the third, so I want it to come down to me".
Much can be learnt about the design of user interfaces by considering this, apparently, simple interface. If you think about the elevator button problem you will find out that something so simple has hidden depths. How do people learn about elevator calling? What's the right amount of information to present to people? Do people need to know where the elevator is, or just that it's coming? Are up and down buttons necessary? What about having a single call button?
1. I don't know how I learnt that the correct thing to do was press the button indicating the direction I wished to travel. It's sort of elevator folk wisdom. Somehow you learn through experience or an elder passing on the knowledge. I have never actually seen an elevator with instructions. Have you?
So, it's quite natural that some people won't have learnt the user interface of an elevator. If you are designing a user interface it is worth stopping and pondering the things you assume 'everyone knows' about it.
2. The information about the current floor the elevator is on actually presents a problem for the caller. It is additional information that the person I interrogated assumed was needed to make a decision. Sometimes extraneous information takes on an importance all of its own. Here the user was assuming that you needed to know where the elevator was.
Actually all you need to know is that the elevator system has responded to your request and an elevator is coming.
3. Another oddity is that you call the elevator with up and down buttons (indicating a travel preference) and then get in the elevator and press a button. There's nothing to stop you contradicting yourself by indicating a different direction of travel. This makes you wonder why you had to indicate the direction in the first place.
Typically, you have to tell the elevator your direction because an arriving elevator may already have people in it who have already instructed it to go to a certain floor. Thus the elevator is going up or down. If you register your request then the elevator can tell you whether it can meet that request.
4.3 PROPOSED SOLUTION
ü The best solution to this problem is to install a dedicated cooling system for the elevator equipment room. The system should be designed to keep the temperature and humidity within the recommendations of the elevator manufacturer. Openings to the outside should be sealed to help limit the dust and dirt that can enter the equipment room.
ü Wait times and elevator speed should be checked on a regular basis. Time how long it takes to go from the bottom floor to the top floor. Measure the time spent waiting for an elevator during peak and off-peak periods. Record the times and compare them to a baseline for the elevator, or to the manufacturer’s specifications for that type of application.
ü I suggest that, a faster control system technology should be use in designing elevator system. By doing this the average waiting time and other similar elevator problems would be solve, especially because of the new component incorporated into the system.
ü One interface optimization would be to replace the up and down with a single call button. Passing elevators would stop and indicate which direction they were travelling. This simplifies the interface while placing a burden on the system which will perform wasteful stops for people who want to travel in the opposite direction. Here is where UI and internal system dynamics trade-off. A UI decision might actually make the system less efficient.
ü The problem can be solve if a wireless call button is place inside the offices of a very busy sky scraper so that people can call the lift before they get to the lift lobby.
4.4 PIC MICROCONTROLLER
Research into microcontrollers led to Microchip’s PIC microprocessor line
The PIC line consists of hundreds of different microcontrollers ranging from 8 to 64 pins, and a host of features such as Analogue to Digital conversion, pulse width modulation (PWM) ports, and more. It was also discovered that many robotics projects used the PICs because of their many features as well as a low cost to feature ratio. One of the most important aspects considered when choosing the PIC was the many programmers available for this line of microcontrollers. One of the best aspects of the PIC microcontroller is that Microchip has a sampling program which allows the PICs to be used for free.
Research into popular PIC chips pointed to two chips as the most commonly used. The 16F84A, an 18 pin PIC, was incredibly popular and many websites were dedicated just to this microcontroller. The other popular chip was the 16F877A which features 40 pins, thus making it more appropriate for larger projects. With 33 of the 40 pins on the 16F877A available as I/O pins, including 8 channels of 10 bit analogue to digital conversion, and a generous 8192 instructions of space in the FLASH memory, the PIC is suitable for very complex tasks.
|
 |
Figure 4.2 PIC process diagram
4.5 ELEVATOR SYSTEM OPERATION FLOW
Figure 4.3 shows the elevator system operation flow. This figure consists of floor where passenger wants to visit. Elevator car moves it either upward or downward direction. The arrival sensor detected the arrival of the elevator to the respective floor. Floor button is used to take the elevator to the respective floor. Floor lamp shows the indication of floor and direction lamp shows the direction of elevator movement, whether it is upward or downward direction. Elevator button is used for moving the elevator car either in upward and downward direction. Based on the elevator switch pressed, the elevator car is moved either in upward and downward direction. D.C. Motor is another important component of elevator system. Based on the switch pressed, the D.C. Motor either moves in forward and reverse direction to move the elevator in either upward or downward direction. Door of the elevator system is one of the important factors of elevator system. When elevator car stops in particular floor, the door of the elevator is opened for passenger to be come out and come in to the elevator car. Arrival sensor is used in every floor, for detecting the elevator car. When a particular car is reached to the particular floor, this arrival sensor detects the elevator car and stops that car.
Figure 4.3 elevator system operations
4.6 DISPACHING STRATEGY
When User presses an elevator button, the elevator button sensor sends the elevator button request to the system, identifying the destination floor the user wishes to visit. When any new request comes, this new request is added to the list of floors to visit. If the elevator is stationary, the system determines in which direction the system should move in order to service the next request. The system commands the elevator door to close, when user presses the elevator door closed button. When the door has closed, the system commands the motor to start moving the elevator, either in up and down direction, based on switch pressed. When the elevator moves between floors, the arrival sensor detects that the elevator is approaching a floor and notifies the system to stop the elevator and open the door of the elevator system. Figure 4.4 shows the elevator dispatching strategy.
 |
Elevator user
Figure 4.4 dispatching strategy
Description:
1. User presses an elevator button to go up. The elevator button sensor sends the elevator button request to the system, identifying the destination floor the user wishes to visit.
2. The new request is added to the list of floors to visit. If the elevator is stationary, if there are other outstanding requests, the elevator visits these floors on the way to the floor requested by the user, following the above sequence of dispatching and stopping. Eventually, the elevator arrives at the destination floor selected by the user.
4.7 ANALYSIS DIAGRAM
4.7.1 Use case diagram
Most system interacts with human that use the system for some purpose, so both human and actors expect the system to behave in predictable way. A use case models the behaviour of the system or a part of the system, which is a description of a set of sequences of actions, including variants that the system performs to yield any observable result of value to the actor.
Figure 4.5 use case diagram of elevator system
Use case diagram models the dynamic view of the system. Use case diagrams are central to modelling the behaviour of a system, a subsystem or a class. The main content of a use case diagram includes uses cases, actors, dependencies, and generalisation and association relationship.
Figure 4.6 class diagram (the object oriented view)
4.7.2 State chart Diagram
A State chart diagram shows a state machine. Usually the state machine in a state chart models the behaviour of a reactive object, whose behaviour is best characterized by its response to events dispatched from outside its context. The object has a clear lifetime whose current behaviour is affected by its past. State chart diagrams are important for constructing executable systems through forward and reverse engineering.
Figure 4.7 state charts for drive control
It is admitted that there exists a gap in the process of designing a system from requirements to state charts, not enough direction methods can be followed when drawing the state chart diagram from the requirements. In this section, some practical methods used during our designing the state charts for the elevator system are introduced. These methods may not be as serious as rules or instructions of how to draw state chart diagrams from the requirement document, but they are helpful in practice.
Figure 4.8 state charts for door control
CHAPTER 5
DESIGN
5.1 Hardware design
The objective of the hardware design is to develop the interface circuit between the PIC and the elevator system and the elevator control panel, with both external and internal requests. These requests are produced by push buttons that send continuous signals to the PIC when activated. Each push button is connected to an LED to identify the request placed. In addition, the four floors are represented by four LEDs, one for each level. Furthermore, an alarm switch is installed to produce a flashing signal whenever activated. This facility was introduced to simulate the desire for a sudden stoppage of the elevator either for reasons of safety or for requests for a repair job to be carried out on the elevator.
In order to obtain the desired setup, we needed to find a way to capture the pulse generated by a depressed push button. We also needed to make sure that the PIC is recognising these signals in order for it to correctly perform the required action. The circuit diagram of the elevator control system layout is shown in Fig 5.1 where both the interface between the PIC and the elevator system with the control panel are drawn.
Figure 5.1 the circuit schematic diagram of the elevator control system.
5.2 Description of the interface circuit
The hardware components used in the project are listed below:
PIC 16F877, LM 293, 2x16 LCD, SEVEN SEGMENT, BUZZER, LIMIT SWITCH SENSORS, Voltage supply, Push buttons, LEDs, resistors, relays, a switch, and connecting wires respectively.
Since the number of required inputs and outputs respectively, matches the maximum input/output capability of the PIC used, there is no need for any multiplexing or de-multiplexing operations. Thus all inputs and outputs used can be directly controlled by the PIC.
As shown in figure 5.1, the push buttons were connected to the PIC, since the PIC needs continuous signals to process, and so do the lights that indicate the requests placed. The flip flop holds the signal until the reset is activated. The reset of the flip flop is the level position for levels L1 and L4. So when the elevator reaches one of these two levels and a request is placed the output will reset the requested signal. However levels L2 and L3 are reset by software. The reason for that is because L2 and L3 are intermediate level.
Figure 5.2 top view of the PCB design
5.3 Software design
The elevator system may run in an intelligent control. In order to achieve the complete design, all possible transitions and stages the elevator system has to go through were considered and a complete flowchart was drawn for this.
Start
|
NO
 | |||
 | |||
YES
NO
|
| |||||
 |  | ||||
YES
 |  | ||||||
| |||||||
| |||||||
YES NO
 |  | ||||||
 | |||||||
 | |||||||
NO
Figure 5.3 program flow charts
The flow chart show how the program control each component of the system and input send to the controller are process according to users request, it was only possible to do this because the program was design with a dedicated measures to control the PIC pins and associate them with their specific function and task in the system. Since everything included in the flow chart is clearly define in program and as it relates to other subroutine, each input and output were clearly define to suit the design functionality.
5.3.1 PROGRAM COMMAND FLOW AND ISR FLOW CHART
Start
 |
YES
 |
Figure 5.4 program command flow chat
Start
 | |||
 | |||
YES
 |
NO
|
|
 |  | ||||
 | |||||
Figure 5.5 interrupt service routine (ISR) flow chart
5.3.2 Intelligent control
The intelligent control responds to requests placed by users by ordering and processing them in an intelligent manner. This type of control is used in most applications requiring modern elevators. Hence only the intelligent mode was designed and implemented as discussed here.
The intelligent control is based on taking all requests and ordering them in an
Intelligent manner such that the earlier-mentioned compromise between energy
Consumption and speed of response is met.
5.3.3 Description of the operation of the elevator under intelligent control
The elevator starts at level 1. It opens the door for 5 s, then checks for requests in upper levels. The movement from one level to another is represented by a timer. The transition between two successive levels takes 8 s. As soon as a request is serviced, the door opens for 5 s to take passengers in, and then proceeds to the next request to be serviced.
Whenever a level is passed by, its light flashes for 1s to indicate the current position of the elevator on its way to its required destination. The requests whose direction (up or down) is similar to the current direction of the elevator are always serviced before those made in the opposite direction, regardless of which requests were made first.
The system continues to service all the remaining requests in a similar way. Whenever no more requests are left to service, the elevator will simply remain at the level it was last at, keeping the door open for 5sec and then closing it until a fresh request is made.
However the door is programmed to never open in between levels and whenever the alarm switch is activated, the alarm signal starts flashing and the elevator stops at the next immediate destination, opens the door and freezes all requests until the alarm is set off again.
An illustrative example on the intelligent control of the elevator is explained below:
Assume the following requests: 2D, 3U, 4D, were made and the elevator is currently at level 1. The PIC will then perform the following sequence: First, all up requests are serviced, i.e. in this case only 3U will be serviced. Next the elevator reaches the fourth floor to service 4D, and finally it services the remaining down requests, which in our case is 2D.
L. Cheded and M. Al-Mulla
International Journal of Electrical Engineering Education 39/2
CHAPTER 6
TESTING AND IMPLEMENTATION
6.1 Testing
The testing of the elevator control system involve a procedure to verify if the component propose for the design can actually be use or need some modification in the main circuit diagram. However, I employ the breadboard in other to understanding whether or not the system is working according to the specification and meet the objective of the project.
Figure 6.1 breadboard connection test
All the component use in the circuit diagram can be seen in the breadboard connection of figure 6.1 above. In testing of the circuit, I use a 9v small battery the voltage was regulated by the LM7805 which a positive voltage regulator IC with a fixed output voltage of 5V and that is the system voltage requirement. This makes the PIC totally essentially indestructible because of the power output of the system.
When the power is switch on, the system is initialise and can be seen in the LCD display screen showing where the elevator ‘call:’ from outside is displayed and ‘lift:’ which is where the inside floor number is displayed. At this point the system is at initial condition or reset.
Figure 6.2 LCD initialisation of elevator control system
Figure 6.3 accepting user request.
The above picture in fig 6.3 depict a user request being process, from ground floor the user press a button indicating to go up to level 3 and the system accept the request and go to the desire destination with the direction up. Although the picture is not very clear but the testing met the objective of the project.
6.2 Implementation
The implementation of the hardware part of the project is being considered and demonstrated effectively in this section. However, converting the specifications on paper into a physical entity was a time consuming process of trial and error. By using microcontrollers, updating the code to control the events and inputs was a simple as removing the PIC and reprogramming it. By choosing to implement the system in modules, each individual unit was tested and the design validated before integrating it with the main system. This method make it easier for checking errors and making the system response to be effective, which is very important as regarding internal external system design. The elevator control system hardware was indeed implemented as contend in project aim and objectives stated in the previous section. Figure 6.4 below shows the completed hardware of the elevator control board.
Figure 6.4 completed hardware of the elevator control board.
In the fig.6.4 above, it is very clear to see all the component use to implement the elevator control system for this project.
The display unit show that the elevator or lift is at standby waiting user request from any floor and the seven segments is also displaying zero (0) which means that the lift is currently on ground floor, that is the initial lift position when the power is switched ON.
The lift control system is now set to accept and process user request. You will notice that in fig.6.5 below, two users on the same floor and they all request for the lift to go to different floor lower than their current floor (level 3) 3 is displayed on seven segment. UserA press 2 while userB press 1and you can see that the direction is down (Dwn), so the lift is now moving to their desire destination but must stop userA at 2rd floor and then proceed to the next down(floor 1) which is userB desire destination without stopping the motor.
Figure 6.5 accepting and processing of user request
CHAPTER 7
CONCLUSION AND FUTURE WORKS
7.1 Conclusion
In this paper, the successful design and implementation of the intelligent control of a 4-level elevator control system using only one PIC was discussed. The design includes a simple scheme that aims at a good compromise between energy consumption and speed of response without requiring any extra circuitry. Some suggestions as to how to extend the design to handle a larger number of floors were also given. Finally, it is hoped that this work has demonstrated that, despite their limited control capabilities, small educational PICs, when fully exploited, can indeed tackle industrial control of modest size in a cost-effective way.
In second approach, four types of dispatching algorithms were implemented for elevator system using microC. Elevator control system uses this algorithm in different situation for smooth operation and reduces the average waiting time of passenger and power consumption of elevator system. The behaviour of elevator system is improved by choosing the one algorithm out of four based on the possible traffic situation. All the algorithms share the same type of FSM, which control the elevator system operational function correctly.
7.2 Suggestions for extending the current system to a higher than 4-level elevator system
The elevator system designed and implemented in this project was restricted to four levels. This restriction was due only to the limited number of inputs and outputs provided by the PIC used. However, to extend the system to more than four levels, some suggestions are made below:
Suggestion 1
Use a more powerful PIC. PICs come in different sizes and with various capabilities. When increasing the number of levels in the elevator system, the designer must identify the number of inputs and outputs required to select the most suitable PIC.
Suggestion 2
Use two PICs working together. One PIC can be dedicated to the control of the lower four floors while the other controls the upper three floors. Information about the switch from the set of four floors to the set of three floors and vice-versa can be transmitted from one PIC to the other via two communication lines.
REFERENCES
1) Control System Design and Analysis: A Linear Matrix Inequality
Approach by Kazuo Tanaka, Hua O. Womg, John Wiley and Sons
Publications.
2) Fuzzy Controller by Leonid Rezmik Victoria University of Technology,
Melbourne, Australia, Newnes Publication.
3) Kim, C. B., Seong, K. A., Kwang, H. L., Kim, J. O,“Design and implementation of a fuzzy elevator group control system”. IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans 1998 28 (3), 277–287.
4) Perdita Stevens and Rob Pooley. Using UML, Software Engineering with Objects and Components.
5) http://webster.cs.ucr.edu/AoA/Windows/HTML/CPUArchitecturea3.html
6) http://www.stanford.edu/~sidseth/files/lift_controller.pdf
7) Department Of Measurement and Information Systems, "Microprocessor based elevator controlling system", version: FLV-V02.1, 1989 (Project report in Hungarian)
8) Sajjan Shiva, “Computer Design and Architecture”, Marcel Dekker, 2000, ISBN 0-8247-0368-5
9) Alen Clements, “The Principles of Computer Hardware”, Oxford, 2000, ISBN 0-19-856454-6.
10) M. Morris Mano, “Computer System Architecture”; Prentice Hall, 1993; ISBN 0-13-175563-3.
11) James O. Hamblen and Michael Furman; “Rapid Prototyping of Digital Systems’; Kluwer
12) http://tams-www.informatik.uni-hamburg.de/applets/hades/webdemos/95-dpi/pic16f84-elevator5/elevator.html (program code reference here). I. Warnock,
13) Programmable Controllers (Prentice Hall, Englewood Cliffs, 1988).
14) J. W. Webb, Programmable Logic Controllers: Principles and Applications (Macmillan, New York, 1988).
15) M. Al Mulla, Control of a 4-level Elevator System Using a Programmable Logic Controller, Senior Project, Systems Engineering Department, KFUPM, September 1988.
16) John P. Hayes(computer architecture and organisation)third edition.
APPENDIX A
Motor interface diagram
Voltage regulator pin diagram
APPENDIX B
The program code for the elevator system
//define lift switch
#define sw_flr1 PORTA.F0
#define sw_flr2 PORTA.F1
#define sw_flr3 PORTA.F2
#define sw_flr4 PORTA.F3
//define switch call from outside
#define call_flr1 PORTA.F5
#define call_flr2 PORTE.F0
#define call_flr3 PORTE.F1
#define call_flr4 PORTE.F2
//limit switch for sensor
#define sensor_flr1 PORTD.F0
#define sensor_flr2 PORTD.F1
#define sensor_flr3 PORTD.F2
#define sensor_flr4 PORTD.F3
//pin for motor n buzzer
#define motor_fwd PORTC.F0
#define motor_rwd PORTC.F1
#define buzzer PORTC.F2
#define led PORTC.F3
//pin for 7segment
#define segment_a PORTC.F4
#define segment_b PORTC.F5
#define segment_c PORTC.F6
#define segment_d PORTC.F7
#define segment_e PORTD.F4
#define segment_f PORTD.F5
#define segment_g PORTD.F6
#define sec_flag flag.F0
//define variables
char status_flr; //which floor
char flag; //flag for timer
char call_flag; //calling lift flag
char direction; //direction lift
char msec,sec,minutes,timer1; //timer
//define subroutines
void start_gf(void);
void display_flr(void);
void display_direction(void);
void detect_call_floor(void);
void update_floor(void);
void open_door(void);
void close_door(void);
void up();
void down();
void stop();
void beep();
void check_call_floor(void);
void door();
void lcd_floor(void)
{
lcd_out_cp(" Floor");
}
//***************************************
//timer intterupt
//calculate time in msec,sec
//to count every sec passed
void interrupt(){
if (INTCON.T0IF){
asm{clrwdt}
msec++;
if (msec >=30){
msec = 0;
sec++;
sec_flag=1;
if (sec >=60){
sec = 0;
minutes++;
}
}
}
}
//***********************************************8
//main routine
void main()
{
ADCON1=0x06; //define io ports
TRISA=0xFF; //porta as input for switch
TRISB=0x00; //portb as output for lcd
TRISC=0b00000000; //port as output 7segment
TRISD=0b00001111; //portd 0-3 input, the rest output
TRISE=0b00000111; //porte,0,1,2 is input for switches
OPTION_REG=0b00000101; //set timer ratio 1:64
INTCON = 0xA0; // Enable TMRO interrupt
PORTA=PORTB=PORTC=PORTD=PORTE=0x00; //clear all ports
LCD_Config(&PORTB,6,5,4,3,2,1,0); //initialise lcd to portb
Lcd_Init(&PORTB); // Lcd_Init_EP4, see Autocomplete
LCD_Cmd(LCD_CURSOR_OFF); // send command to LCD (cursor off)
LCD_Cmd(LCD_CLEAR); // send command to LCD (clear LCD)
call_flag=0; //clear call flag
status_flr=0; //clear floor to start from 0
//main routine
do
{
if(sec_flag) //check every second
{
display_flr(); //display floor at 7segment
display_direction(); //update direction
sec_flag=0; //clear second flag once done
}
update_floor(); //check sensor and update floor status
detect_call_floor(); //check if cal button or lift button press
check_call_floor(); //check if floor is reach, stop n open door
}while(1) ; //reloop again
}
//******************************************
//check floor with call switch
void check_call_floor()
{
if(status_flr==0 && call_flag.F0==1) //if lift at gflr and ppl call from gflr
{ //then ignore
}
else if(status_flr==0 && call_flag.F1==1) //lift is at gflr and ppl call from 1st flr
{
up(); //status go up
}
else if(status_flr==0 && call_flag.F2==1) //lift is at gflr and ppl call from 2nd flr
{
up(); //status go up
}
else if(status_flr==0 && call_flag.F3==1) //lift is at gflr and ppl call from 3rd flr
{
up(); //status go up
}
else if(status_flr==1 && call_flag.F0==1) //lift is at 1st flr and ppl call frm gflr
{
down(); //status go down
}
else if(status_flr==1 && call_flag.F1==1)
{
}
else if(status_flr==1 && call_flag.F2==1)
{
up();
}
else if(status_flr==1 && call_flag.F3==1)
{
up();
}
else if(status_flr==2 && call_flag.F0==1)
{
down();
}
else if(status_flr==2 && call_flag.F1==1)
{
down();
}
else if(status_flr==2 && call_flag.F2==1)
{
}
else if(status_flr==2 && call_flag.F3==1)
{
up();
}
else if(status_flr==3 && call_flag.F0==1)
{
down();
}
else if(status_flr==3 && call_flag.F1==1)
{
down();
}
else if(status_flr==3 && call_flag.F2==1)
{
down();
}
else if(status_flr==3 && call_flag.F3==1)
{
}
if(call_flag==0x00) //if call flag is done
stop(); //then stop at positon
}
//******************************************
void up(void) //routine to go up
{
direction=1; //direction =1
motor_fwd=1; //motor move forward
motor_rwd=0;
delay_ms(50); //delay 50msec
}
void down(void) //routine to go down
{
direction=2; //direction =2
motor_fwd=0; //motor move backward
motor_rwd=1;
delay_ms(50); //delay 50msec
}s
void stop(void) //routine to stop motor
{
direction=0; //direction =0
motor_fwd=0; //stop mot0r
motor_rwd=0;
delay_ms(50); //delay 50msec
}
//*******************************************
//routine to detect calling floor
void detect_call_floor(void)
{
lcd_out(1,8,"Call:"); //display call on lcd
if(!call_flr1) //check if ppl press call flr1 switch
{
lcd_chr(1,13,'0'); //display 0 on lcd
call_flag.F0=1; //call flag.F0 will on
}
else if(!call_flr2) //check if ppl press call flr2
{
lcd_chr(1,14,'1'); //display 1 on lcd
call_flag.F1=1 ; //call flag.F1 will on
}
else if(!call_flr3)
{
lcd_chr(1,15,'2');
call_flag.F2=1;
}
else if(!call_flr4)
{
lcd_chr(1,16,'3');
call_flag.F3=1 ;
}
//****************************
//detect siwtch from inside
lcd_out(2,1,"Lift:"); //display lift
if(!sw_flr1) //if sw1 press
{
lcd_chr(2,6,'0'); //display 0 and call flag on
call_flag.F0=1;
}
else if(!sw_flr2)
{
lcd_chr(2,8,'1');
call_flag.F1=1 ;
}
else if(!sw_flr3)
{
lcd_chr(2,10,'2');
call_flag.F2=1;
}
else if(!sw_flr4)
{
lcd_chr(2,12,'3');
call_flag.F3=1 ;
}
if(status_flr==0 && call_flag.F0==1) //when at gflr and call flag for glfr is on
{
lcd_chr(1,13,' '); //clear outside lcd
lcd_chr(2,6,' '); //clear inside lcd
call_flag.F0=0; //clear flag
stop(); //stop
display_direction(); //display stp at lcd
display_flr(); //display floor position
beep();beep(); //beep 2x
delay_ms(1000); //delay 1sec
door(); //show open n close door at lcd
}
else if(status_flr==1 && call_flag.F1==1)
{
lcd_chr(1,14,' ');
lcd_chr(2,8,' ');
call_flag.F1=0;
stop();
display_direction();
display_flr();
beep();beep();
delay_ms(1000);
door();
}
else if(status_flr==2 && call_flag.F2==1)
{
lcd_chr(1,15,' ');
lcd_chr(2,10,' ');
call_flag.F2=0;
stop();
display_direction();
display_flr();
beep();beep();
delay_ms(1000);
door();
}
else if(status_flr==3 && call_flag.F3==1)
{
lcd_chr(1,16,' ');
lcd_chr(2,12,' ');
call_flag.F3=0;
stop();
display_direction();
beep();beep();
delay_ms(1000);
door();
}
}
//update floor at 7segment
void display_flr(void)
{
if(status_flr==0) //show 0 a 7seg
{
segment_a=1;
segment_b=1;
segment_c=1;
segment_d=1;
segment_e=1;
segment_f=1;
segment_g=0;
}
else if(status_flr==1) //when floor at 1
{
segment_a=0;
segment_b=1;
segment_c=1;
segment_d=0;
segment_e=0;
segment_f=0;
segment_g=0;
}
else if(status_flr==2) //when floor at 2nd
{
segment_a=1;
segment_b=1;
segment_c=0;
segment_d=1;
segment_e=1;
segment_f=0;
segment_g=1;
}
else if(status_flr==3) //when at 3rd floor
{
segment_a=1;
segment_b=1;
segment_c=1;
segment_d=1;
segment_e=0;
segment_f=0;
segment_g=1;
}
}
//display direction
void display_direction(void)
{
if(direction==0) //when direction=0 then show stp
lcd_out(2,14,"Stp");
else if(direction==1) //when direction=1 then show up
lcd_out(2,14,"Up ");
else if(direction==2) //when direction=2 then show Dwn
lcd_out(2,14,"Dwn");
}
//****************************************
//routine to check sensor
void update_floor(void)
{
if(sensor_flr1 && !sensor_flr2 && !sensor_flr3 && !sensor_flr4) //when sensor1=1 and rest=0
{ //when 1000
status_flr=0; //then lift is at 0
}
else if(!sensor_flr1 && sensor_flr2 && !sensor_flr3 && !sensor_flr4) //when sensor 0100
{
status_flr=1; //lift at 1
}
else if(!sensor_flr1 && !sensor_flr2 && sensor_flr3 && !sensor_flr4) //when sensor 0010
{
status_flr=2; //lift at 2
}
else if(!sensor_flr1 && !sensor_flr2 && !sensor_flr3 && sensor_flr4) //when sensor 0001
{
status_flr=3; //lift at 3
}
}
//*****************************************
//routine to beep buzzer
void beep(void)
{
buzzer=1;
delay_ms(100);
buzzer=0;
delay_ms(100);
}
//**************************************
//open and close
void door(void)
{
lcd_out(1,1,"Open "); //display open
beep();
delay_ms(1000); //delay 1sec
lcd_out(1,1,"Close"); //display close
buzzer=1; //on buzzer
delay_ms(500); //delay 0.5sec
buzzer=0; //off buzzer
}