September 22, 2008
Muni Bids Adieu to OS/2
Anyone who follows Muni knows to roll their eyes when the subject of ATCS comes up. That's the lousy old software that controls the trains in the subway -- it was supposed to speed things up when it was installed back in the 90s, but as we know, subway service is slow slow slow. It's also to blame for those incomprehensible maps displayed on the flat-screens on the platforms. And now, finally, it's close to getting a makeover.
On the agenda for a Wednesday meeting of the SF County Transportation Authority: allocating $300,000 for a variety of projects, including an upgrade for the ATCS network platform from OS/2 to Windows. (Yes, OS/2. Our subway runs on OS/2. You're not surprised, are you?)
Hopefully this will mean faster operations and better support; but as Rescue Muni pointed out a year ago, system upgrades at Muni are often accompanied by disastrous hiccups. We can't wait!
| 
add to stumble upon
add to reddit
email this
add to facebook
add to del.icio.us
Good luck. OS/2 was what the ATM's used to run. No idea what they run nowadays on, but it was meant for stability. 'upgrade to windows' sounds like a nightmare to happen... if at least it would be Linux :)
Hey! OS/2, while antiquated, is rock-solid and performs well. OS/2 is NOT a bad OS, and I'd say it's arguably better than any version of Windows.
The ugly-looking track display is because of the software that generates the display, not the OS. If they just port the software, it will look exactly the same no matter what it's running on.
A move to Windows could in fact hurt the stability of the system -- arguably stuff like this should be running on some sort of UNIX or a high-stability RTOS like VXWorks.
In and of itself, OS/2 is not a bad choice considering the time-frame that choice was made. And quite frankly, in the grand scheme of things, moving the system to Windows is a far worse decision.
They should be moving to Linux platform. And although there may be some hardware considerations that prevent that--doubt it though it's possible--at the same time, moving to a free and open platform should allow budget to level any hardware to that platform to gain long-term viability. Windows cannot be a long-term plan; 3-5 years tops.
It just seems that the majority of the time that the organization continually makes really poor and short-sighted choices. Most unfortunate.
I can see it now. 20 years from now we collectively groan when we find out Muni still runs on XP Home Version.
Worst Video Game Ever...
I'd rather see Atari 800 Sim Train on those displays than another Blue Screen of Death.
Running critical infrastructure on Windows is an enormous mistake.
Sad to say, keeping OS/2 is probably the better option. And you can do really modern things with OS/2 these days -- it even runs Firefox 3.0!
As much as the mere mention of "OS/2" makes me all nostalgic for the Mojave-esque OS/2 Warp ads of the mid 90s and reminds me of how old it is, the thought of MUNI running on Windows terrifies me.
*Nix or bust. Seriously.
Not a chance. Linux just doesn't have the lobbying power of Microsoft or IBM, though IBM possibly lost out on a Linux oppo here. I'll bet Microsoft is on the backend of most government technology.
Using OS/2 or moving to Windows isn't the scary part. Age isn't an issue here either. Despite some fundamental flaws, BART's ATCS isn't anywhere near as bad as the MUNI one... and it's been in use for far longer.
The scary part is that the MTA wants to remove the old cab signaling system (what was in place before the new fangled crap) so your choices in the subway are ATCS or sub-25mph fully manual-call-central-control-at-every-switch mode. Given how astoundingly reliable the ATCS getup has been... ugh.
@ Travin
naw duders.. it will be Windoze ME (MUNI edition)
There's always Mac. It's that right windows (as Mac smacks him with a frying pan).
upgrade: I don't think that word means what they think it means.
As someone who has professionally written software for everything from windows 3.1 to VMS, it doesn't matter all that much what the OS is. What does matter is the quality of the code in the actual switching software. Most likely windows was chosen because developers are generally more available.
As for the speed of muni, were any of you actually taking the underground before the switching software was put in place? I was and when it went into place my commute got 10-15 minutes faster on average.
As for Bart, how many individual trains do they have moving through the tunnel at any given time? Oh yeah it's an order of magnitude faster.
@ mushmouth, reasonable points but I wonder, considering how much difficulty muni drivers have with running into people and other trains, if increased speed is what they really need.
Muni trains in the subway can't go faster than 35 (the feds say there's braking problems), what makes this go any quicker?
Ever noticed that the trip between Castro and Forest Hill is much slower?
mush: eh? It takes me 15 minutes to get from Daly City to Powell. If you're spending more than fifteen minutes in the MUNI portion of the subway, you're likely looking at mechanical failure. Consider that when the ATCS was introduced, the "unreliable" Boeing cars were replaced too.
'Course that all misses the point. My point was not that the cab signaling system was superior (it is). My point was that the cab signaling system allows trains to be run at faster speeds than if they had to do it manually. Cab signaling is far superior backup to ATCS than doing everything by hand.
zippy: Daly City to Powell is indeed about 15 minutes on BART which I consider to be a pretty reasonable amount of time. If you take the nearest Muni train (the M at 19th Ave. and Randolph) it takes about an hour on average to make the same trip and doesn't really go to that many other locations to warrant it: basically just SF State, Stonestown, and West Portal. Forest Hill, Castro, Church, and Van Ness might as well be Balboa Park, Glen Park, 24th Mission, and 16th Mission as there it's entirely underground (and, as such, would be the best way to compare underground efficiency... ignoring the lunacy of keeping the damn thing above-ground to make a few stops that could easily be moved underground).
I suspect that the greater problems for Muni are traffic from running on the street (idiocy! and an attempt to save a few bucks by piggybacking on the old streetcar tracks), their usual issues with being unable to keep to a schedule, and the clumping that Muni so often has on all of its other lines.
@ BillyShears: "This is totally liquid..."
Its funny that SFIst bitches about MUNI so much since they deal with what 100th of the traffic and how often do I see stuff like this
Safari could not open the page “http://sfist.com/mt/plugins/Profile/profile.cgi” because the server is not responding.
or
Got an error: Can't locate object method "instance" via package "MT::Plugin::Profile" (perhaps you forgot to load "MT::Plugin::Profile"?) at /home/httpd/local/mthost/blogs.gothamistllc.com/httpdocs/mt/plugins/Profile/lib/Profile/App.pm line 27.
15 minutes was my speedup going from the Sunset Tunnel West to Embarcadero station when they put the switching software in place.
As for putting tunnels that follow the bart line, or anywhere else in the city, I don't know where you are going to get the money, but subways cost $1 Billion/Mile have any idea where that sort of cash is coming from?
So Muni is controlled by a 486sx sitting in a basement somewhere. Why am I not surprised?
And let me guess... those "switching problems" are when they have to reboot, right?
mush: got that. I can traverse a longer stretch of subway in less time by taking BART. That's my point. The old signaling system was not to blame for the snails pace through the MUNI Metro. Shitty equipment and incompetent employees are to blame.
belgand: Not counting the time it actually takes to enter West Portal station (usually 2-5 minutes...) it took me longer to go from WP to Powell than it does Daly City to Powell. I save about an hour a day by driving to DC BART over taking MUNI. Quite frankly there's not usually that much traffic on Taraval.
Akit: that may very well be the case legally, but the trains regularly go faster than 35mph in the subway. Powell to Montgomery is usually, what, 45mph? The maintenance tech that made it out to FH to check out the brake problems took us from FH to Castro in excess of 50mph. That was a couple months ago. Wheee.
Quit Whining and use your head.
Bart has dedicated, bart only roads, its amazing that when you have your own road that does nothing but allow one train to go through every 10 minutes you can go faster. But what is the cost, the dedicated lane (the land costs something in lost tax revenue), the additional upkeep over the highway, running the nearly empty train. The point is there are MUCH better things to spend money on in this city than any sort of subway. BTW bart peaks out at what 10 trains an hour through the tunnel? MUNI does 40 trains an hour, so yeah Bart can go faster. How much would that extra 20mph save you in the market street tunnel? 1 minute? 2 minutes? it ain't much, as it would only hit that peak speed in a few places as it is.
mush: still don't get it, eh?
I'm comparing the private RoW of the BART tracks to the private RoW of the MUNI tunnels. So, eh.
Depending on the time of day, ten BART trains are going to be 80-100 cars. Forty MUNI trains are, at most, 80 cars, probably closer to 60 because of the routes which can't handle two car trains. 'Course BART is already running sub-ten minute headways at peak times anyhow.
MUNI fixated on the number of trains per hour in the tunnels with the advent of the ATCS. Unfortunately this completely ignored that pre-ATCS trains were longer (seen any three or four car trains recently?)... and that the end result was reduced throughput.
I don't think you get it.
How many different routes does bart run through the city? Oh yeah one. How many stops does it make? How long does the average city resident have to walk to get to a bart station?
There may be 10 cars on a single bart train, but guess what, they all go to the same place, and for the most people who live in the city, that place isn't all that conveniently located. Long trains have it's use, but spreading out to the neighborhoods and stopping every few blocks is not one of them.
Bart cost's a lot more per rider and is subsidized far more than muni, sorry it's simply not a viable solution.
I think you're both arguing about different things.
How many routes? Four. And, no they don't all go to the same place. They merge at West Oakland. If the merging of four routes presented significant delays, you'd see that in increased headways in San Francisco.
MUNI's subsidy per rider is lower because the cost of running trolley diesel buses is far lower than the cost of trains. If you compare the cost of MUNI rail to BART rail, it's not nearly as big of a gap.
Streetcars and subway cars are indeed very different things, which is why it's foolish for MUNI to try and combine them.
Updating the ATCS isn't that scary. Abandoning the backup to the ATCS is. The difference between 15mph and 35mph is indeed significant. I'm not quite sure where you're coming up with the idea that trains don't (or shouldn't) move any faster than 15mph in the subway. ::shakes head::
This is so typical of the uninformed bashing that takes place - OS2 was selected as the most reliable at the time OS for the management level of the ATCS - the system had been demonstrated reliable and, typical to all software development MUNI code was adapted from other projects to save money and development time. Remember this was back in 1989-90 - you Monday morning quarter backs suggest they should have used Windows 3.1? Or let me guess UNIX that would give you prettier pictures in the subway?
The safety critical system does run on three cross checked redundant industrial 486s. 486s were actually an upgrade to ensure they commands to and from the wayside and trains had enough time to get sent with a full fleet in the subway. Industrial 486s were the only hardware that had the reliability numbers needed to achieve the ridiculous up time that is needed. If one 486 doesn't agree with the other 2 it shuts down. If two don't agree your commute sucks. The central safety computer issues safety sensitive commands to both the wayside and the trains. The wayside and trains have 8088 CPUs, two each, also cross checked and redundant. They require further communications integrity to issue a command to a signal or switch or train (i.e. you gotta tell them more then once what you want or it wont happen)
The max speed in the subway is 50mph, the trains will do 52.5 in auto before ATCS will slow them down. Pre ATCS you could run maybe 20 trains an hour, now you can run 48 for sure, 60 is the spec but there have never been enough trains to actually run a fully loaded test. Other then a communication based train control system the alternative was to build more tracks i.e. more tunnels. Anyone checked the price on that lately? Pre ATCS the limiting factor to throughput was track circuit length. Some track circuits in the MUNI subway are 3000 feet if not longer. That means one train in 3000 feet, with ATCS you can have trains much much closer and still be assured of safe separation. Actual distance is dynamic and depends on the train speed direction and operating mode in front of your train.
If San Franciscan's would stop insisting on custom solutions such as moving steps on the trains and dreams of automatic coupling you could have better reliability - learn to use off the shelf technology - pick a high floor or low floor train and invest in the needed infrastructure to run that design and stop whining about operating systems.
Mike:
Pre-ATCS you were able to run trains that were up to four cars long. You were able to double berth. Now the trains are half as long, and you can only board one train at a time. Currently MUNI is closer to 40 trains per hour. 60 may be the spec, but there's zero chance of that ever being met. Capacity has not increased significantly. ATCS was a solution to a non-problem (trains per hour). At the time, the moving block system was indeed a custom solution.
Regarding redundancy. So what? Having redundant systems doesn't mean that they're reliable. I've been onboard for five spurious emergency brake applications this year. Apparently it was worse when the ATCS was first introduced. Yes, that's the safe solution to problematic communication... but people still get hurt... and the system is still not reliable.
By its very definition, the LRVs are custom designs. It's not a matter of merely high and low platform, MUNI is trying to combine orthogonal designs: streetcar and subway car.
The SF Weekly did a piece ages ago about how the Breda cars were created...it's a pretty twisted tale. Breda's cars for Boston are so bad, they spend more time in maintenance than they do on the tracks.
Why?
Because they didn't' design them for Boston's specific needs - they just copied the specs from the ones they built for MUNI, not realizing that the terrain, weather, etc in Boston is not at all like SF.
As for the OS2 situation...I'd be curious to read the EULA for whatever OS they pick. I know if you buy a Mac, they have specific language about not using your mac to run a nuclear power station, etc.
I maintain the OS/2 software that runs the New York City subway system. Too bad the software in San Francisco isn't better, but I expect it's not the fault of the operating system.
I can't blame SF for changing the OS when they upgrade -- I'd like to help them maintain what they've got, but I'm busy with NYC.