Self restarting property of RTOS-How it works?

Yes, it need not be sensitive to inter-packet timing. It has been about 25 years since I looked at this stuff, but that sounds like IBM Bisync which used two SYNC bytes (thus bi-sync) to train the clock. I don't recall how Bisync avoids mixing up data with SYNC bytes.

In HDLC/SDLC uses 01111110 as a special flag value. To ensure it does not mix with the data, when it the xmitter sees 5 '1' bits in a row, it jams in a '0' bit. The receiver later drops the jammed '0'. NRZi encoding represents a '1' as no change and a '0' as a change (inverting of state) in level. Combining SDLC and NRZi ensures there is a transition at least every 5 bit times so a Phased Locked Loop can recover the clock from the data stream.

Other data encoding methods, such a FM0, FM1 or Manchester (used by Ethernet) ensure there is a state transition for each bit so the clock can always be recovered by a PLL. However these double the transmission frequency.

Eric

You mean make the elevator utilization more efficient? They'd sell less elevators. The people in that business know something about more elevators or they wouldn't be in business. :)

Maybe because the system does know either the remaining capacity of all elevator cars nor how many people are waiting at each floor?

If the system sends too mare cars to a request, the cost is momentary inconvenience for the passengers of the extra car. If the system sends too few cars to a request, some people get annoyed.

Suppose you write software at an elevator controls company. Which way would you want the system to act?

Kelly

That's part of it.

No, you have got that wrong. If it sends too many, the effect is that the average waiting time goes up for 'random' use patterns.

With prescience.

Regards, Nick Maclaren.

Well there is enough UML examples around to help them with that problem!

Actually, sending two elevators down to the ground floor makes sense. If you only send one down, it's coming right back up and you'll have both elevators at the upper floors again. Send two down, and one stays down waiting at the ground floor.

Interestingly, there's an algorithm called the "elevator algorithm" which is used for position the head assembly on a disk drive. Basically, the elevator starts wherever it is (naturally!) and goes up, stopping only at floors where either somebody inside the elevator or somebody waiting on that floor has pressed the button for that floor. It goes up to the highest floor for which service was requested and then uses the same simple algorithm on the way back down. It's not optimal (in terms of either throughput or wait times), but it's simple to implement and provides decent performance for non-degenerative cases (which is to say, real life!) You could calculated maximum wait time pretty easily, but how would you estimate average wait time?

Ed

Some elevators are very well programmed indeed:

There are circumstances when it makes sense, but you should think that one through a bit more. Think of a precise, reasonable model (i.e. one that does not involve the accumulation of people inside the building) and work it out. Quite subtle differences in the model can lead to big differences in whether particular naive rules help.

It is a hell of a long time since I looked at this one (and I never looked at it closely), but I can remember that none of the naive algorithms are much use in practice. There ARE some good ones, but even they have problems.

Regards, Nick Maclaren.

... snip ...

I would expect better algorithms would await better input methods. For example, instead of selecting from 'up' or 'down', the prospective rider could select the destination floor. Now an arriving car has to display which floors it will handle, and separate the sheep from the goats. The sheep and goats have to be sufficiently alert to be separated. Maybe something along the lines of "take a ticket" based on rfids would work.

In article , CBFalconer writes: |> |> I would expect better algorithms would await better input methods. |> For example, instead of selecting from 'up' or 'down', the |> prospective rider could select the destination floor. Now an |> arriving car has to display which floors it will handle, and |> separate the sheep from the goats. The sheep and goats have to be |> sufficiently alert to be separated. Maybe something along the |> lines of "take a ticket" based on rfids would work.

Yes. As with all such issues, a very small amount of extra information can make a great deal of difference. Similarly, you could have a special program for rush hours (and the morning one might be very different from the evening one). What becomes very clear on a fairly casual inspection is that understanding the properties of the input data is a prerequisite to designing good algorithms.

This is very, very relevant to telecommunications and many aspects of computing, as all experts in the relevant aspects know very well. I know just enough to have a glimmering of the depths of my ignorance :-)

Regards, Nick Maclaren.

The key word here is "can". In thinking about this particular possibility, it seems the big advantage would be if one could have multiple elevators where one would service the "higher" floors and one the "lower". Then the people going to the higher ones wouldn't have to wait for all the stops in the lower ones. This is probably only usefull for fairly tall buildings. In fact, for such buildings, something like this is frequently done. I have been in buildings with multiple banks of elevators each clearly labeled with the range of floors they service. While this doesn't have the flexibility of being able to change the floors serviced dynamically, it avoids the need for dynamic "sheep/goat separation", (with presumably a higher mistake rate than a static system) as described above.

I think this is pretty standard for tall buildings.

Absolutely. And, since the elevator companies have been at this for something like a century now, the have worked out an awful lot of the "best practices".

Absolutely.

Me too. :-)

Already done, in the tall buildings. There the problem is to conserve elevator shaft space. Works something like airline hubs and feeder lines.

And I've seen proposals (still in the gee-whiz) stage to have an "up" shaft, a "down" shaft and a few cross-shafts, with motors in the elevator cars so they have more autonomy for getting up and down.

It was a popular science kind of thing -- I have no idea if it's being seriously developed (but it'd be fun to do the software!).

Google "wonkavator" (:

That is a different solution. What you are talking about is "stacked" elevators, where you have to get off at some intermediate floor and switch to another elevator. That is the only way to conserve shafts. What I was talking about was where all the elevators went to the lobby, but only to a subset of the upper floors. Doesn't conservve shafts, but reduces total time for those wanting to go to the upper floors, as they don't have to wait through all the stops on the lower ones.

I've been in two buildings in recent years where the elevator user interface works just in that way. One is ~30 stories, but the other is only 14, IIRC. Both have access control via RFID cards, and those cards can be programmed to either just allow a single floor - no need to enter the data then - or a range of floors. Once the desired floor has been entered (explicitly or implicitly), the display will show the letter of the elevator that will service you. For larger parties, it is recommended to enter the data more than once.

Jan

Compared to the quality of say the "average" ethernet controller out there these don't seem to be all that major bloopers?

The WTC AFAIK had two sorts of elevators: express ones, which could go up to levels divided by 20 or so (each of them single source/single destination, so that the elevators took less from the office space in the precious upper floors), and slower ones, which shared the shaft space, and could only reach up within the express lift granularity. To use the vertical space even better, it could be possible to have a several-level express lift, i.e. with entrances in several levels, but still with the +-20 floors (or whatever) granularity.

If I was to build a skyscraper, I would build a big, fast, several-level wide-granularity express elevator (a "vertical subway") in the core of the building, complete with own air supply and water coolant for fire emergency use, and the slow elevators as panorama elevators on the outside. That way, no shaft space is used for the slow elevators (all elevator doors are windows when no elevator is there).