Skip to content

erikliland/TTK4145-Elevator

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit

src

src

 
 

README.md

README.md

 
 

main.go

main.go

 
 

startExternElev.sh

startExternElev.sh

 
 

Repository files navigation

Elevator Project

Summary

Create software for controlling n elevators working in parallel across m floors.

Main requirements

Be reasonable: There are surely many semantic hoops that you can jump through to create something that is "technically correct". Contact us if you feel that something is clearly ambiguous or missing from these requirements.

No orders are lost

  • Once the light on an external button (calling an elevator to that floor; top 6 buttons on the control panel) is turned on, an elevator should arrive at that floor
  • Similarly for an internal button (telling the elevator what floor you want to exit at; front 4 buttons on the control panel), but only the elevator at that specific workspace should take the order
  • If the elevator is disconnected from the network, it should still serve whatever orders are currently "in the system" (ie whatever lights are showing)
    • It should also serve the internal orders, so that people can exit the elevator even if it is disconnected

Multiple elevators should be more efficient than one

  • Distribute the orders across the elevators in a reasonable way
  • You are free to choose and design your own "cost function" of some sort: Minimal movement, minimal waiting time, etc.

An individual elevator should behave sensibly and efficiently

  • No stopping at every floor "just to be safe"
  • The external "call upward" and "call downward" buttons should behave differently
    • Eg if the elevator is moving from floor 1 up to floor 4 and there is a downward order at floor 3, then the elevator should not stop on its way upward

The lights should function as expected

  • The lights on the external buttons should show the same thing on all n workspaces
  • The internal lights should not be shared between elevators
  • The "door open" lamp should be used as a substitute for an actual door, and as such should not be switched on while the elevator is moving

Start with 1 <= n <= 3 elevators, and m == 4 floors. Try to avoid hard-coding these values: You should be able to add a fourth elevator with no extra configuration, or change the number of floors with minimal configuration. You do, however, not need to test for n > 3 and m != 4.

Unspecified behaviour

Some things are left intentionally unspecified. Their implementation will not be explicitly tested, and are therefore up to you.

Which orders are cleared when stopping at a floor

  • You can clear only the orders in the direction of travel, or assume that everyone enters/exits the elevator when the door opens

How the elevator behaves when it cannot connect to the network during initialization

  • You can either enter a "single-elevator" mode, or refuse to start

How the external (call up, call down) buttons work when the elevator is disconnected from the network

  • You can optionally refuse to take these new orders

Simplifications

Try to create something that works at a base level first, before adding more advanced features. You are of course free to include any or all (or more) of these optional features from the start.

You can make these simplifications and still get full score:

  • At least one elevator is always alive
  • Stop button & Obstruction switch are disabled
    • Their functionality (if/when implemented) is up to you.
  • No multiple simultatneous errors: Only one error happens at a time, but the system must still return to a fail-safe state after this error
  • No network partitioning: A situation where there are multiple sets of two or more elevators with no connection between them

Evaluation

Dates to be decided.

  • Completion
    • The elevator system works in accordance to the main specification
    • The student assistants will use a checklist of various scenarios to evaluate this
  • Design
    • The system is robust: It is always in a fail-safe state where no orders are lost
    • You will create a short presentation about your fault tolerance strategies (More details to come)
  • Code Review
    • Code quality: Well written, structured, easy to navigate, consistent, etc.
    • Idiomatic wrt. the language (Using the language the way it is supposed to be used)
    • Maintainability: Separated into modules, APIs are complete, easy to swap out pieces of code
    • Ease of adding features you simplified away (if any)
    • Demonstrate understanding of your own code
    • (More details to come)

Language resources

We encourage submissions to this list! Tutorials, libraries, articles, blog posts, talks, videos...

Other

You are encouraged to exchange ideas with your fellow students. Or, to put it another way: You are required to exchange ideas with your fellow students.

Be gentle with the hardware. The buttons aren't designed for bashing. Sliding the "elevator" up and down is fine. Make sure no cables are dangling behind and under the workspace.

Drivers

Are found in the directory called driver

Contact

Any questions or suggestions to this text/the project in general?

Send an email, a message on It's Learning, open an issue, or create a pull request.

About

NTNU TTK4145 Real-time programming, Elevator project

Resources

Readme
Activity

Stars

2 stars

Watchers

3 watching

Forks

0 forks
Report repository

Releases 1

Project delivery Latest
May 6, 2015

Packages

No packages published

Languages