Introduction
Purpose
This document aims to deliver a comprehensive and consistent overview of the software requirements for an elevator controller It will utilize textual descriptions to clarify concepts, various diagrams to depict complex interactions, and tables to organize and present relevant information effectively.
This document is aimed at all stakeholders involved in the development of elevator controller software, including software developers, project managers, quality assurance teams, and customers.
Scope
The elevator controller's software plays a crucial role in ensuring the safe and efficient operation of the entire elevator system Its primary function is to process input signals from various components and generate appropriate output signals Key responsibilities include managing a queuing system for passenger requests and directing elevator cabs between floors based on those requests Additionally, the controller is committed to passenger safety, achieved by interacting with dedicated components that monitor essential environmental attributes.
The controller operates using a consistent algorithm to handle requests, without adjusting its behavior based on the volume of incoming requests or the current environmental conditions.
This SRS document exclusively addresses the software requirements for the elevator controller, omitting any hardware specifications or requirements for other components of the elevator system While interactions with other system components influence the controller's requirements, details regarding those components and the overall elevator system are beyond the scope of this document and are not included.
Definitions, Acronyms, and Abbreviations
Sheave: A component with a groove around its circumference to support and contain a rope or cable and a bearing at its center to permit rotation about a shaft [2]
Terminology
Elevator doors are the inner doors of an elevator cab and the corresponding outer doors located on the elevator shaft at the same floor where the cab has stopped.
The door opening mechanism of an elevator cab simultaneously operates both the inner cab door and the outer shaft door, making it unnecessary to distinguish between the two.
A position marker is a device located along the side of an elevator shaft, which is detected by a sensor on the elevator cab These markers are strategically placed throughout the shaft's height, allowing the sensor to relay information to a computer about the cab's position One common type of position marker is a hole, which aids in accurately determining the elevator's location within the shaft.
An active floor request occurs when a summon or floor button is pressed, indicating the need for an elevator cab This request remains active until an elevator arrives at the designated floor, at which point it becomes inactive.
References
[1] How Stuff Works “How Elevators Work” http://science.howstuffworks.com/elevator.htm, accessed on Nov 3, 2005
[2] Glossary of Rigging Terms http://www.sapsis-rigging.com/Glossary.html, accessed on Nov 3, 2005
[3] Elevator – Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Elevator, accessed on Nov 3, 2005
Overview
The rest of this SRS document contains all of the requirements for the elevator controller presented in several ways and organized into different sections
Section 2 contains general information that is not too specific and is provided as a background for the following sections It contains descriptions of all of the other elevator components that the controller interacts with, as well as a context diagram that illustrates the entire elevator system It also lists product functions, constraints, and assumptions about the controller Section 2 is a good section for customers to read
Section 3 contains more detail and presents the requirements with many different diagrams that illustrate the functional requirements of the elevator controller Some of the types of diagrams that are used here include, sequence diagrams, state diagrams, and collaboration diagrams There is also a part of this section that describes the interface between the controller and the rest of the elevator system as a set of signals Section 3 is most suitable for developers and testers
Section 4 of the SRS contains supplementary information required to complete the document’s breadth It includes tables of all of the functional and non-functional requirements, as well as a table for each use case of the elevator controller Both the requirements and the use cases are cross referenced with each other to provide traceability among both types of artifacts.
General Description
Product Perspective
The elevator controller directly interacts with the following other components of the entire elevator system:
Summon buttons are located on a panel outside elevator shafts, allowing potential passengers to request an elevator cab to their floor Each floor features two buttons—one for going up and another for going down—except for the top floor, which has only a down button, and the bottom floor, which has only an up button The elevator controller receives signals when these buttons are pressed and released, indicating the desired direction and floor, while also sending light signals to show the buttons' status.
The elevator controller manages six-floor cabs within a six-story building, featuring floor request buttons labeled 1 through 6 in each cab Passengers use these buttons, located on the interior panel, to select their desired floor The controller processes the pressed signals to determine the requested floor and cab while also sending light signals to indicate the button status.
The Open Door Button, located on the interior button panel of each elevator cab, allows passengers to open the elevator doors or keep them open while the cab is stationary at a floor Unlike some elevator systems, this particular model does not feature a close door button The elevator controller responds to the Open Door Button by detecting signals when the button is pressed and released, including the specific cab from which the signals originate.
The interior button panel of each elevator cab features a button that allows passengers to stop the elevator at any time When pressed, this button signals both the elevator system and the originating cab, ensuring immediate attention to the request.
The button located on the interior panel of each elevator cab allows passengers to sound a bell, alerting individuals outside the elevator shaft in the event of a malfunction When pressed, this button sends a signal to the elevator's controller, indicating that assistance is needed for someone trapped inside.
The Service Switch is a crucial feature of elevator systems designed to prevent elevator cab movement and to keep the doors securely closed or open This functionality is particularly beneficial when loading large items, such as furniture, into the elevator The elevator controller communicates with the switch, receiving signals when it is set to either AUTO or HOLD mode AUTO mode allows for standard operation, while HOLD mode ensures the elevator cab remains stationary and the doors do not open or close, enhancing safety and convenience during loading activities.
Each elevator cab features an interior display that shows passengers their current floor Unlike some systems that have floor number displays outside the elevator doors, this particular system does not Instead, the controller communicates with the display, sending signals to indicate the appropriate floor number.
Elevator cabs are equipped with a direction display that shows whether the elevator is moving up or down This display receives signals from the elevator controller, which determines and communicates the appropriate direction for the display to indicate.
Each elevator cab is equipped with a load sensor that monitors the weight inside at all times This sensor sends signals to the controller whenever there is a change in the total weight, providing information about the new load and the specific cab from which the signal originates.
Each elevator cab is equipped with a position marker sensor that identifies specific markers located inside the elevator shaft This sensor communicates with the elevator controller by sending signals whenever it detects a position marker, including the identification of the originating elevator cab.
The emergency bell within the elevator system serves as a crucial alert mechanism for notifying individuals outside that someone is trapped inside the elevator cab This bell is activated by the controller, which sends a signal to ensure the alarm rings, facilitating prompt assistance for those in need.
Each cab is equipped with a load bell designed to alert passengers when the weight exceeds safe operating limits The controller activates the load bell by sending a signal, ensuring safety and proper function during operation.
Each elevator cab is equipped with a door opening device that simultaneously opens both the inner cab door and the outer shaft door at each floor This device operates through a controller that sends and receives signals to manage the door operations, ensuring they open and close completely Additionally, the signals provide information about the specific cab involved in the process.
The elevator engine plays a crucial role in moving the elevator cab vertically between floors, utilizing a roped mechanism connected to a sheave The elevator controller communicates with the engine by sending signals that dictate the desired speed and direction of movement To halt the elevator, a stop signal is issued by setting the speed parameter to zero.
Product Functions
The elevator controller plays a crucial role in the elevator system by receiving and processing signals from various components It sends out responses to these signals, ensuring the seamless operation of all parts of the system This continuous exchange of signals allows the elevator controller to maintain smooth and efficient elevator performance on a daily basis.
Here are a few of the following ways the controller interacts with the other components of the elevator system:
• Controls the speed of elevator engines in order to move elevator cabs up and down their respective shafts
• Queues and processes elevator summons and floor requests from passengers through the signals provided to it by several buttons
• Processes information sent to it by load sensors in order to ensure that the load of a cab never exceeds the safety limit
• Processes information sent to it by position marker sensors in order to keep track of where the elevator cabs are at all times, as well as their speed
• Provides feedback to passengers through the lights on some of the buttons and the floor number and direction displays in each cab
• Can sound alarm bells that are either invoked by trapped passengers or required to warn of excess load in a cab
• Controls the operation of the elevator doors of a cab through communication with door opening devices.
User Characteristics
The elevator controller interacts primarily with other components of the elevator system, which must be capable of sending and receiving signals in a compatible format This ensures effective communication between the controller and components like elevator engines and door opening devices Additionally, these components must promptly process and respond to signals from the controller to maintain the elevator system's efficiency and prevent delays.
General Constraints
The hardware that the elevator controller software will be running on may constrain some design decisions pertaining to timing and performance, as well as signal communication
Public safety regulations mandate specific requirements for elevator controllers, ensuring the safety of the elevator system The controller must effectively manage a set of constraints designed to uphold these safety standards.
• The inner doors of a cab should not be opened unless the cab is at a correct floor position and is stopped
• The outer doors of a shaft should not be opened at a particular floor unless there is a cab stopped at that floor
• An elevator cab should not start to move until its doors are completely closed
• The acceleration and deceleration of a cab must be gradual enough to prevent the injury of any of the passengers inside
A cab must not return to normal operation if its total weight exceeds the safety limit; it is essential to reduce the weight below this limit before resuming service.
• If the controller detects a malfunction in any of the other vital components of the elevator system, it must halt the operation of the affected cabs immediately.
Assumptions and Dependencies
The following is a list of assumptions made about the elevator system that affect the elevator controller:
• There are 6 floors that the elevator system provides service to
• There are 2 elevator cabs that the controller is responsible for, each operating in its own, separate shaft
The elevator system's performance should be efficient, but the controller does not need to make special adjustments for peak traffic times or sudden spikes in call requests.
The controller interacts with various system components by sending and receiving signals that adhere to a specific protocol or standard.
The elevator system is equipped with various emergency functions, each managed individually by the elevator controller When emergencies arise, the controller addresses them separately, as there are no overarching emergency modes activated For instance, pressing the emergency bell button triggers a specific response from the system.
This only causes the emergency bell of the system to ring, nothing more o Emergency Stop button Pressed
When the emergency stop button is pressed, the cab it controls halts, while the controller stays active to accept requests from other functional cabs This ensures that even if one cab is stopped, it can resume operations once normal conditions are restored Notably, a subsequent press of the emergency stop button on a halted cab will reactivate its normal functioning Additionally, the load sensor is designed to detect excessive weight.
Excessive weight in the cab impacts its performance, but requests continue to be logged and queued by the controller without triggering any emergency operation mode.
In emergencies, manually switching a cab into hold mode is possible, but it is not always required The controller continues to function normally, considering the held cab, without entering a specific emergency operation mode.
Specific Requirements
Functional Requirements
Figure 2: Sequence Diagram of UC1 – Process Pressed Signal from Summon Button ôsystemằ
Door Opening Device Engine Direction Display
Place Summon Request in Queue
Remove Summon Request from Queue
Summon Button Position Marker Sensor
Marker Detected( cab ID ) loop [The cab is not at its destination]
[A cab was already at the floor that the summon button was pressed from]
Pressed( floor number, direction ) alt
Figure 3: Sequence Diagram of UC2 – Process Released Signal from Summon Button ôsystemằ
Start timer for automatically closing the doors
[a cab was already stopped at the floor that the summon button was released from and the doors of the cab are open]
Pressed( floor number, direction ) opt
Figure 4: Sequence Diagram of UC3 – Process Pressed Signal from Floor Request Button ôsystemằ
Door Opening Device Engine Direction Display
Place Floor Request in Queue
Determine When Request Should be Answered
Remove Floor Request from Queue
Floor Request Button Position Marker Sensor
Marker Detected( cab ID ) loop [The cab is not at its destination]
[The cab from which the floor button was pressed is already at the floor specified by the pressed button]
Pressed( cab ID, floor number ) alt
Figure 5: Sequence Diagram of UC4 – Process Pressed Signal from Open Door Button ôsystemằ
Elevator Controller Open Door Button
[the cab from which the open door button was pressed is not moving and is stopped at a floor]
Pressed( floor number, direction ) opt
Figure 6: Sequence Diagram of UC5 – Process Released Signal from Open Door Button ôsystemằ
Start timer for automatically closing the doors
[the cab is stopped at a floor and the doors of the cab are open]
Pressed( floor number, direction ) opt
Figure 7: Sequence Diagram of UC6 – Process Pressed Signal from Emergency Stop Button ôsystemằ
Marker Detected( cab ID ) loop [The cab is not stopped]
Position Marker Sensor alt [The cab is not currently stopped by the emergency stop button]
Figure 8: Sequence Diagram of UC7 – Process Pressed Signal from Emergency Bell Button
Figure 9: Sequence Diagram of UC8 – Process HOLD Mode Signal from Service Switch
Figure 10: Sequence Diagram of UC9 – Process AUTO Mode Signal from Service Switch ôsystemằ
Resume normal operation of the elevators
Figure 11: Sequence Diagram of UC10 – Process Weight Changed Signal from Load Sensor
Figure 12: Sequence Diagram of UC11 – Process Signal from Position Marker Sensor ôsystemằ
Door Opening Device Engine Summon Buttons
Turn Light Off Open Doors
Remove Summon and Floor Requests from Queue
Position Marker Sensor Floor Number Display loop [The cab is not stopped]
[The cab has changed floors]
Marker Detected( cab ID ) opt
Calculate the new position of the cab opt [The new floor that the cab is on has an active floor request within this cab or an active summon]
Figure 13: Sequence Diagram of UC12 – Process Turn Off Signal from Operator ôsystemằ
Position Marker Sensors Engines All Buttons
Marker Detected( cab ID ) loop [The cabs are not stopped]
Figure 14: Sequence Diagram of UC13 – Process Turn On Signal from Operator ôsystemằ
Figure 15: Sequence Diagram of UC14 – Process Doors Opened Signal from Door Opening Device ôsystemằ
Start timer for automatically closing the doors
The summon button on the floor where this cab is stopped is not being pressed, and the open door button for the cab is also not being activated.
Doors Opened( cab ID ) opt
Figure 16: Sequence Diagram of UC15 – Process Doors Closed Signal from Door Opening Device ôsystemằ
[There is an active summon or floor request on another floor in the queue that is not being handled by another cab]
Doors Closed( cab ID ) alt
Clear Determine which floor this cab should go to next from the queue
Figure 17: High Level System State Diagram
Shut Down Complete Initialization Complete
Figure 18: Operating Elevator State Diagram
Figure 18 illustrates a crucial state diagram that highlights the significant concurrency within the elevator controller This concurrency is vital, as it ensures that input signals are processed immediately upon receipt, preventing any loss of signals due to the controller being in a specific state A detailed analysis reveals the presence of six distinct sub-states, each playing a critical role in the system's functionality.
Operating Elevator state must run within the controller concurrently
In systems with high concurrency, data synchronization issues can arise, but managing the controller's primary data queue is straightforward The logging sub-states are designed to add requests to the queue, while the dispatching sub-state processes and removes them Since the controller does not enter specific emergency modes, the three sub-states can function concurrently without issues For instance, even if the emergency stop button is activated in one cab, it does not prevent other cabs from logging requests The stopped cab can later resume processing requests from the queue once it returns to normal operation.
Figure 19: Dispatching Requests State Diagram
Determining Best Cab to Answer Request
Determining Next Request To Process from Queue
With two cabs available, one cab can respond to a request while the controller simultaneously searches for another request for the second cab This efficient process is facilitated by creating a separate thread for each cab's control through a fork.
Queue Checked [Queue is Empty]
Queue Checked [Queue not Empty]
The fork depicted in Figure 19 is crucial as it indicates that once the optimal cab is selected for a request, the process splits into two distinct paths One path manages the chosen cab to fulfill the request, while the other returns to the initial state to check for additional requests This bifurcation is essential because the elevator controller can simultaneously operate two cabs Consequently, the controller does not wait for a cab to complete its current request before dispatching the next; it assigns requests immediately after delegating them to a cab If both cabs are occupied with requests, the controller remains in its current state.
“Determining Best Cab to Answer Request” until one of them becomes free
Figure 20: Controlling Cab State Diagram
New Direction and Speed Calculated / Engine.Move( speed, direction ), DirectionDisplay.Show( direction )
Waiting for Marker Detected Signal from Position Marker Sensor
Calculating New Cab Position and Floor Number
Position Calculated / FloorNumberDisplay.Show( floorNumber )
Checking if Cab is at Destination Position
Cab Position Determined [Cab at Destination Position] /
Remove Summon and Floor Requests for this Floor from the Queue
[Cab not at Destination Position]
Cab Stopped and Doors Closed
Calculating New Direction and Speed
Request Retrieved, Loaded, and Analyzed
Cab Stopped at Destination FloorPositionMarkerSensor.MarkerDetected( cabID )[cabID == this cab]
Figure 21: Cab Stopped at Destination Floor State Diagram
Signal from Timer to Close Doors / DoorOpeningDevice.CloseDoors()
OpenDoorButton.Pressed( cabID ) [cabID == this cab] /
Doors Closing SummonButton.Pressed( floorNumber, direction )
[floorNumber == floor that cab Is on] /
Cab Stopped at Destination Floor
DoorOpeningDevice.DoorsOpened( cabID ) [cabID == this cab] /
Start Timer to Close Doors Automatically
OpenDoorButton.Pressed( cabID ) [cabID == this cab] OR
[floorNumber == floor that cab Is on] /
Restart Timer to Close Doors Automatically
LoadSensor.WeightChanged( cabID, newWeight ) [cabID == this cab AND newWeight > safetyLimit] / LoadBell.Ring(), DoorOpeningDevice.OpenDoors() Stop Timer to Close Doors Automatically
LoadSensor.WeightChanged( cabID, newWeight ) [cabID == this cab AND newWeight > safetyLimit] / LoadBell.Ring()
LoadSensor.WeightChanged( cabID, newWeight ) [cabID == this cab AND newWeight