Elevator control system demonstrating Erlang/OTP upgrades.
The recent updates includes:
- The corresponding
gen_statem
calls have been added to replace the deprecatedgen_fsm
behaviour. However, thegen_fsm
calls have been left in and can be used through conditional compilation. - The former
rebar
andrelx
tools have been replaced withrebar3
and therebar3_relx
plugin. - The calls to the deprecated
gs
(graphics system) module have been replaced with a mock module (gs_log
) in order to enable us to check the workings of the rest of the updates. Hopefully, a proper graphic interface will be added in the near future :)
Further details can be found in the wiki.
Originally written by Håkan Huss in the late 90s at Erlang Systems.
It was part of the 5-day Erlang Literacy course aimed at test and support staff of the GPRS project. It was used as a lab exercise in several parts of the course to practise different topics such as behaviours, supervisors, release handling, etc. The first exercise using the elevator example was the mentioned "bug" that the elevator always stopped at every floor (it is actually not a bug, but an elevator scheduler which is trivially guaranteed to fulfill the requirements on elevator scheduling used in the example). Several refinements of the scheduling were made in the course lab exercises.
Since the purpose of the exercise was to use many different aspects of Erlang and OTP, the code has been written to use many behaviours rather than to be the "best" solution for the problem. The resulting architecture should still be pretty good, though.
It has also been used to demonstrate how Quick Check can test elevator systems, and featured in a few academic papers.
Thanks go to Francesco Cesarini and Håkan Huss for the historical informations.
In 2013 Loïc Hoguin made the software avialable in a public repository, and made the announcement on the Erlang mailing list. The repo received some updates during 2013 and 2014. This repo is the continuation of the earlier efforts.
- Make sure you have
make
andrebar3
installed and in your$PATH
- Type
make
to build everything - Start the release with
./_build/default/rel/elevators/bin/elevators console
-
Make elevators move and notice they stop at each floor
- There is no GUI, so you will need to use
gs_log
, and your imagination, instead :-( gs_log:fbutton(F)
generates the event for the call button on floorF
.gs_log:ebutton(E, F)
generates the event for the floorF
button in elevatorE
.- The type and range of
E
andF
are not checked. In the real GUI you can only click on buttons with valid values. - Bad
E
will cause crash and restart of the elevatorscheduler
. - Bad
F
will cause an elevator to move indefinitely! - In the log output,
{move,{0,10}}
indicates elevator moving down{move,{0,-10}}
indicates elevator moving up- It takes 8 moves in the same direction to move to the next floor.
{fill,cyan}
indicates door openning/opened.{fill,black}
indicates door closing/closed.- when an elevator arrives at a floor, the door opens, and after one second it closes again.
- There is no GUI, so you will need to use
-
(Exercise: Find bugs, fix them and build a release upgrade)
-
Place fixes in
upgrade/scheduler.erl
-
Run
./v1to2.sh
Note that v1to2.sh
will build the releases in _build/
and deploy
them in _tmp/elevators/
. The _build
and _tmp/elevators/
directories are deleted and recreated each time the script is run!
You can also use rebar3 shell
to start the simulator and experiment
with it.
- Run
./v1to2.sh
cd _tmp/elevators
./bin/elevators daemon_attach
to connect to the server- have a play ...
- leave the console with
ctrl-D
- using
ctrl-C
orctrl-G
to exit will also stop the simulator!
- using
- live switch between the two versions with:
./bin/elevators downgrade 1.0
./bin/elevators upgrade 2.0
The current compilation process prepares the demo entirely, but doesn't double check things. If something fails during the compilation or the release generation, you might want to reset the working directory.