I realize this isn't an ideal question, but i'll do my best to explain it :)
Firstly, the scenario is that I have been tasked for creating a simulation of a building with multiple elevators.
Let's assume my building consists of between 2 and 5 elevators, and an arbitary number of floors. The goal here was to allow "People" to board the elevators and travel to different floors.
The key point here is running each of the elevators concurrently.
I have managed to do this in C++ with a Thread for each elevator. What I am struggling to do is think of a simple way to do this with Message Passing in Erlang. I am not asking for a code answer, but moreso, an explanation of how i could approach this problem using message passing. I have of course attempted to read information on the topic, but it's confusing me.
I understand thus far that the threads must communicate via passing Messages to each other. Any help clarifying an approach on this is greatly appreciated. This is not graded homework or anything, and is an exercise for my knowledge.
Final Question: How can I model a building with multiple elevators programmed to operate independently using Message Passing (in Erlang).
Instead of maintaining a shared state, you give each process its own state, and if anything changes you send messages with the update (and associated data) to all relevant processes
What Daniel is calling a process is an Erlang process, not a thread. They might seem like threads, but they are at least as different as they are similar... So it's really best to call them processes.
You need to be careful not to carry with you a C mind set when you come to design Erlang solutions. The point of Erlang is that it's a different paradigm, and whilst Erlang itself is implemented in C and thus everything you do in Erlang is ultimately run in a C thread, it's important to largely forget that and work with the Erlang paradigm instead.
In C are something to be managed, they are tricky and bite you when you aren't keeping a careful watch on them. Erlang processes are wonderful, you can to all intents and purposes spawn an unlimited number of them, and they don't really require any looking after as such.
In your lift scenario, as Daniel said, spawning a process for each lift is a reasonable design. One of the things to consider with Erlang is that numnbers in cases like this don't really matter, once you write a module to model your lift, you can spawn 2 to 5 of them, or 2 to 5 million of them, and you usually find with Erlang that it makes very little difference.
I'm not saying you can't design a broken implementation, but honestly, once you get used to Erlang you'll find it really lends itself to rapid development without the usual parallel and concurrency pitfalls.
As you progress your lift scenario, the right way to take it forwards is to get to know OTP, use something like a gen_server for your lifts, and a supervisor to spawn them dynanmically (or not) from it. If your lift crashes the process will then automatically get replaced/restarted. This is analagous to a lift breaking down (process has died; lift is unavailable) and the repair engineer coming and fixing it (process restarted; lift is available again). What happens to any people in the lift when it breaks down is perhaps a more advanced topic, for which there are a few possible solutions.