There is something wrong with the description of the laptop use (besides calling DOS a language) - on one hand they are running windows 10 with Win98 virtualized. Then they mention Thinkpads circa 2000. I'm pretty sure Win10 won't run on those machines, so I guess the old laptops are for the interface to the train computers - RS-232 is my guess (could be the parallel port). If all they are using the DOS software for is to dump a log from the train, then it sound to me, that sniffing the protocol would be fairly simple. Calling people from bay-area hacker spaces to give them a hand in creating something more modern.
> that sniffing the protocol would be fairly simple
ah yes, "fairly simple". The protocol is not the issue, the data within is. There are hundreds of datapoints, various switching logic, and tons more of 50 years of accumulated cruft. At least. All in a well tested, stable, and understood package. The documentation is probably pretty good but likely has small (but crucial) errors.
It's easy to assume that this would be a simple rewrite, but real engineering (not the kind we do on hacker news! lol) requires tons of planning, testing, and phasing in. This is dealing directly with people's safety after all! It's interfacing with a train control system, not a webapp that turns markdown into memes.
also
> RS-232 is my guess (could be the parallel port)
RS-232 is inherently a serial protocol. If you're using RS-232 since basically ever, it's either a built in serial port, some sort of serial headers, or some sort of usb-to-serial adapter. The parallel port has never been directly used for RS-232 - they are fundamentally different technologies.
In 1990, RS-232 used 25-pin ports (DB25), and the DB9 ports were "new". Why they used 25-pin ports for RS-232 I'm not sure, since only a fraction of the lines (less than 9) were actually used, probably some silly historical reason. 25-to-9-pin adapters were very common then.
The DB25 connector was also used for parallel ports as you said, which caused confusion sometimes. But on a standard PC, the printer port (parallel) was a 25-pin female port, whereas the serial ports (25 or 9 pin) were male.
I guess around 1995 then? Whenever they switched to DB25 to DE9 for serial.
> probably some silly historical reason
original rs232 spec had a lot more signals and capabilities that very few consumer products implemented. So you were expected to have the full connector, even if the lines weren't hooked up.
>I guess around 1995 then? Whenever they switched to DB25 to DE9 for serial.
There was a transition during the 90s where the DB25s were phased out and replaced with DE9s. Computers became more commonplace and popular, and they also became smaller, so the bulky 25-pin port fell out of favor.
Hardware flow control was retained with DE-9. The lines that were dropped included an entire secondary communications channel and timing signals, the sorts of features that I doubt saw much use in personal computers in the 1980's (when it was mostly used for things like modems and printers) and would see even less use today (when it seems to be mostly used for diagnostics ports).
I own a wacky serial cable that has both DB25 and DB9 connectors on both ends and it has saved my ass more than once in the last decade or so. I'm never giving it up.
DE9 ports - get the terminology right! - were introduced on the IBM PC/AT in 1984 so they weren't especially new in 1990.
Indeed, by 1990 DB25 serial had pretty much vanished from PCs, and only existed as a thing that was a pain in the arse to connect to over existing cabling.
As far as I understand there were actually lots of different "RS232" variations. Nowadays I believe everything is asynchronous, which makes many of the pins that used to be connected redundant; lines that carried things like clock or additional flow control related signals. I'm not an expert, I just noticed this looking at old NEC computers.
RS232 itself is a well-defined spec. But you're right. An lot of equipment existed that was only vaguely RS232 compatible. Some of it even predates RS232. For example, the old electromechanical teletype machines send and receive something close enough to RS232 line signalling that you can connect them to a modern computer's RS232 port, if you wire up a tiny analog circuit to convert from telegraph-style current impulses to RS232-style voltage levels. Just set the UART to 50 bps with 5 bit data and 2 stop bits. And don't send anything too soon after a carriage return! Not all UARTs can handle those settings, but that's why such options were in terminal programs back in the day.
One particular thing to note is that on anything IBM PC related the DB25 RS-232 connector has the wrong gender (apparently so that it can be connected directly to modem with DB25 extension cable instead of 1:1 M-M cable as would be expected for RS-232).
Kids nowadays don't understand what it takes to build, battle-test and maintain complex systems over decades in operation. It is a marvel of Engineering (both HW and SW) and the experts are worth their weight in gold. There is much to learn from them.
Do you have any links to where we can read about its architecture and system as a whole?
They were using a ThinkPad from 2000, therefore I was guessing RS232 and not RS-424 or other industrial ports. A laptop for that age would also have a parallel port, so in theory it could be some bespoke parallel protocol, but pretty unlikely.
> It's easy to assume that this would be a simple rewrite, but real engineering
I said - "If all they are using the DOS software for, is to get a log-file from the train, then its probably easy".
The system is from the 70'ies so its very possible that they originally hooked up dumb terminals. Those are even harder to come by today and had no real way of getting data out of (hard-copy of what was on the screen to line-printer perhaps). Old terminal are also very clunky to haul around compared to even an old laptop. So the DOS program could very well just be a VT05 emulator, without any actual program logic built into it.
So no I was not suggesting a rewrite but rather hack something together like some of us old greybeards here on hackernews like to do.
A lot of old industrial equipment used PCs with parallel ports in place of custom controllers. Parallel ports that were on the motherboard and hooked into the southbridge chipset could be accessed by DMA and driven in hard real time which is otherwise practically impossible to achieve on a speculative processor running Windows. The drivers could convert some gcode to digital signals in a ring buffer driven by an interrupt and just let the parallel port output the 5V logic signals to amplifiers, motor drivers, and so on. This was especially important for a lot of machinery because only mass market CPUs were fast enough to i.e. run computer vision to calibrate and then interpolate tool paths for a pick and place machine that placed thousands of components a minute.
MachCNC was a popular CNC controller among hobbyists that exploited this feature, for example. It wasn’t until the explosion in the popularity of 3D printers that open source CNC controllers that could run on a cheap MCU became widely available (Klipper, Marlin, etc)
The manufacturers saved a lot in NRE and manufacturing costs because a driver is a lot cheaper to write than a low volume controller design - with the parallel port they just had to design a board with a parallel port input that fanned out to a bunch of connectors going to off the shelf motor drivers and stuff. It also meant a much better user experience for users and devs alike but starting with Windows 8 drivers could no longer access LPT via DMA for security reasons (everything on the southbridge was exposed including USB iirc).
I suspect theres some proprietary component for which the driver source code was lost so they can’t adapt it to run off a PCI parallel port card (my memory is fuzzy but DMA to southbridge works differently enough from PCI DMA that it’s not as simple as changing the port number) and USB adapters can’t provide the timing guarantees. They could use an off the shelf PCI FPGA card but parallel ports were extremely common all over industry especially with offices printers so it’s very battle tested hardware. Replacing that is just too risky because redundant safety systems are far better at covering for failures than making sure new bugs don’t slip through.
I once used libparport -- a Linux library with hooks into kernel modules -- to obtain sub microsecond timing on custom hardware on a ~2008 Xeon pc. The parallel port has, by modern standards, terrible bandwidth but excellent latency: I waited for an interrupt and then "did a thing" once it was sent. I remember testing the timing with a 500 MHz scope and realising that I couldn't actually measure the timing error or delay accurately once I'd calibrated the whole system.
The parallel port was basically wired as a general purpose ADC and DAC accessible by DMA, as the parent here says. Amazing kit at the time, and free in the context of expensive ADCs requiring custom hardware and difficulty interfacing in comparison.
The problem is that BART doesn't employ talented reverse engineers. There is now way they could afford them in that area.
Also: Talented reverse engineers are hard to find on a good day in any given area. I used to think that my mentors from the start of my tech career were just the baseline level of sophistication you'd expect of any decent software engineer. 20 years later I have seen how few people have the mindset to get into that sort of thing. (And it is a mindset much more than a level of intellect, IMO)
>Also: Talented reverse engineers are hard to find on a good day in any given area
Not true. Have you looked in Europe? It's full of them thanks to the tinker culture and the presence all big anti-malware companies (Esset, Avast, Avira, Bit-Defender, Kaspersky, etc). Plus every single cybersecurity consulting company out there in the world, big and small, has guys who can do reverse engineering for you. There's thousands of these companies, just look them up.
The reason you're probably not finding them is because you're probably not looking for them or that many juniors who don't have the "RE bug" don't stay in that gig professionally too long because, unless you're a zero-day finding God, cashing out six figure CVE bounties and giving Defcon talks, the pay is worse than a webdev doing CRUD since the demand for reverse engineering work is very low and not valued by customers as it's not the kind of job that impacts their sales or share price so they just look to offshore it to the lowest bidder.
I also left the field and moving to cloud engineering since the demand, pay, benefits, respect is so much better.
I wonder to what extent that is still the case. When I graduated 15ish years ago it was definitely true that many of my classmates had those low level skills, and serval of them had written their Masters thesis on something related. However looking at people graduating from the same program today, I hardly see anybody doing that sort of work. Everything is either some sort of high level web stuff or machine learning.
Even the people I knew who had those skills haven't used them professionally in over decade since, as you say, the pay sucks.
It is. The university in my area has a famous master's program for cybersecurity and many grads there know reverse engineering to a degree. And there a
re many such universities in Europe, plus all the Eastern European gray beards who work in the industry since they cut their teeth breaking DRM to pirate games in their youth.
I personally know at least 5 people who can do this work professionally at a consulting company.
This is the interface to the train control system - a primary safety system - responsible for the lives of literally a million people on an average month. Are you prepared to spend months of your lives rigorously testing and phasing this system in? Are you prepared for the intense legal liability if something goes wrong?
If an individual engineer is put in a position where they can endanger lives by accident, there is something wrong with the management and systems in place around that person.
This is a team game. The people figuring out how the comms works and creating tests for those communications then hand their work off to the "rigor" team.
Or do like what the dutch railways are doing: run the old and new systems in parallel on real inputs and check if the outputs match. Then proceed to only use the output for the old system until you're reallyreally sure there's no bugs.
I'd imagine so, I just knew about the dutch railways for certain. IIRC they are doing a mechanized translation from COBOL to C++. The idea being to first test that exhaustively, and then slowly manually translate the COBOL-y-C++ to more idiomatic C++.
>they are doing a mechanized translation from COBOL to C++.
That sounds interesting; do you mean that they are converting the current working system written in COBOL to C++ using a transpiler? Do you have any links to more information on this?
I do mean that. I can't find it now, but I read it some years ago in a news article. The project was slated to run for a loooong time so I've assumed it's still going on.
No problem, a search for "COBOL to C++ transpiler" actually brings up a couple of companies which is interesting. But how do they verify the resultant output? Mere testing cannot be enough for critical systems software.
Yes/no. The (formal) reason SFMTA went with the Thales/Alcatel system was the ability to overlay the new setup over the old. None of the other bidders met that requirement. Depending on the hardware side of things it's entirely possible you couldn't/wouldn't want to run the two systems in tandem with BART.
That said BART wanted to run AATCS trials on the mainline in Oakland. No clue if they actually managed to do that before GE pulled the plug on the project.
Running trains is rather expensive and generally not something you'd do to test software. Especially given that in this case a software crash can result in a train crash.
>responsible for the lives of literally a million people on an average month
Even in 2019, BART never cracked more than 500K station exits per month, and now it is well below half that number[0]. And of those monthly rides, surely a majority of them were the same people taking multiple rides.
Additionally, even a fatal flaw in the software would most likely not result in every one on every train simultaneously dying or even being injured.
100,000s of thousands of people is still a lot of people. my bad
> Additionally, even a fatal flaw in the software would most likely not result in every one on every train simultaneously dying or even being injured.
I'm glad you're so willing to play fast and loose with safety, but I'm not. Not to mention the impact due to lack of trust when an accident happens! I'll leave train systems to engineers who are rigorously testing their implementations, not you, thanks :)
The problem is that BART doesn't employ talented reverse engineers. There is now way they could afford them in that area.
Well, no. Money is not the problem and BART doesn't need reverse engineers. They've already thrown away tens of millions of dollars on a replacement train control system (AATCS). Everyone's favorite defense contractor Raytheon was tasked with the project until they realized they couldn't make it work. Eventually Raytheon pawned the project off on Harmon, which was later bought by General Electric. GE shut the whole thing down because it was going nowhere.
I think most folks here are drastically underestimating the complexity involved in getting a train control system right (and how badly BART botched the original system). Considering that BART dates back to the 70s, DOS and Windows 98 were upgrades. Meanwhile Muni soldiered on with OS/2 for nearly a couple decades.
> I think most folks here are drastically underestimating the complexity involved in getting a train control system right
The phrase "butt-puckering" comes to mind. Ya some whizkid could come along and put something together but they'd be foolish to attempt, there is 1000 atm of pressure to not get one damn thing wrong. All the things currently wrong with the system are grandfathered. One single wrong thing in your new system and you are toasted.
Sure there are safety considerations (and plenty of dramatic safety events from BART), but I'd venture to guess even there it's rarely quite so black and white.
I was actually thinking more of day-to-day nuisance problems than anything else. Things like getting stuck at the station while the train's computer gizmos reboot, stop annunciators getting confused (or out of sync with each other), having to position the train manually within a station. Or even software failures as hardware wears out – shit like that almost always fails in a safe manner. Unfortunately even a safe failure can have massive consequences which raises the cost of failing fast and breaking thing often.
"Finding replacement parts won’t be a problem and DOS is no longer necessary for Allen and his crew, but it will still be bittersweet to say goodbye to trains that they have lovingly kept alive."
So they don't actually use DOS anymore, maybe, or possibly this just means they don't care because the new trains will soon replace the old ones and then DOS will be gone too. It's a poorly written article even allowing for the usual tech mistakes but either interpretation would be reasonable.
The big problem it seems like is Windows Vista dropped legacy support drivers and 16-bit support fifteen years ago, and Windows 10 dropped even more legacy support drivers. So they keep the ThinkPads around because they can't find the drivers for some things anymore. I've run into that a few times, where old drivers were made specifically for DOS 7/8 or even DOS 6 to interface with custom fabricated CNC machines or injection mould machines. In the end the company that originally created those few hundred units no longer exists, and nobody has the floppies that held the original drivers or software. So you keep cloning the drives for when they fail and hoping there's enough near-spec hardware spares to hold out until a total system replacement.
>Calling people from bay-area hacker spaces to give them a hand in creating something more modern.
Tragically, from the small amount of time I've spent in SF, my understanding is this is unlikely to be their first instinct, even if it's a great idea. Doesn't the SF local government have a testy, if not outright hostile relationship with the tech worker/hacker/startup scene?
I've met people from either side of the discussion who pretty much entirely blame the opposite group (hackers or city workers) for why SF is so different now than 'back in the day.'
This is perhaps more specious than the "cops don't want to do their jobs because people are just too mean to them" song and dance. At the risk of putting too fine a point on it BART is not run as part of any city government, San Francisco or otherwise. You're pretty much tilting at windmills here.
Besides this sort of thing is well beyond the scope of folks creating subscription based fruit juicers.
Gotcha. BART being funded by the Bay Area Rapid Transit District is something I'd forgotten, and does make my point a lot less salient. It's been a long time since I was in SF, so it's possible my assessments here are way off base.
The main observation I was trying to make is that the public/private sector has always seemed to have a harder time working hand-in-hand in the Bay Area than it does in other cities I've lived in, whatever that reason may be.
I'm surprised the article didn't mention that BART is the only train in North America on the uncommon 5'6" gauge. This is another factor making parts and equipment more difficult to source.
I don't think most parts and equipment are swappable anyhow. Maybe tracks themselves. But as far as the trains are concerned, you're pretty much buying all of the trains bespoke from the manufacturer.
If SF used standard gauge rail, it's not like they could just buy some surplus rail cars, put some seats in them, and call it a day. Subways are generally lower to the ground because it improves stability and reduces roll. They corner better. I'm not sure that any subway system uses regular old heavy rail train cars.
And besides, if you're ordering thousands of cars for replacement from bombardier (or whomever), you can order spare parts while you're at it.
I don't think most parts and equipment are swappable anyhow. Maybe tracks
themselves. But as far as the trains are concerned, you're pretty much
buying all of the trains bespoke from the manufacturer.
No you're not. Caltrain has plenty of secondhand rolling stock. Some of the newer coaches came from MetroLink, some of the older ones came from a railway in Virginia. Locomotives came from Southern Pacific and Amtrak.
Muni runs all sorts of heritage equipment from around the world on the F, but the PCCs which make up the majority of the fleet were designed as a standard car.
If SF used standard gauge rail, it's not like they could just buy some surplus
rail cars, put some seats in them, and call it a day. Subways are generally lower
to the ground because it improves stability and reduces roll. They corner better.
I'm not sure that any subway system uses regular old heavy rail train cars.
After the PCC of the 50s the feds tried for a next generation. In the end only Boston and SF bought the cars. They were utter crap in large part because (much like BART) it was mostly a pork project for defense contractors. In this case Boeing's new helicopter division (Boeing-Vertol) thought that trains were basically upside down helicopters and would be easy enough to build.
Muni's current trams are based on an off-the-shelf Siemens design. The problem with BART isn't just the axles, it's the entire propulsion system, it's the wacky loading gauge, etc. BART can't even get away with a modified off-the-shelf system.
And besides, if you're ordering thousands of cars for replacement from bombardier
(or whomever), you can order spare parts while you're at it.
Aside from the obvious problems with single sourcing things, that strategy only works as long as you can get spares. BART had huge problems finding thyristors a few years back because they use a non-standard voltage.
Yeah, but Caltrain isn't a subway, it's regularly old heavy rail. Which, like I said, is not generally deployed in subway systems due to size and comfort issues.
As far as the spares are concerned... Yeah, I'm not really sure what to tell you. It's not a problem limited to BART. Most subway cars in the world are produced by Kawasaki, Bombardier, etc. Even still, I wonder how much other cities with standard rolling stock get to reuse parts in maintaining subways? Perhaps you know.
I don't doubt there are other random parts difficult to find or source. Especially from a system that was originally built before electric train standards fully formed. The cost of innovation is maintenance.
Well, no. Maintenance is the cost of stagnation. Look at New York, Chicago, or Berlin to see how electric rail has evolved over the years. BART is still the only system in the world running 1 kVDC. That means no matter who they buy from there's no commonality. For the most part it doesn't matter that Rohr went under. Although per the article current manufacturers are having trouble recreating the cab windows from the original BART cars - something that didn't need to be innovated on in the first place.
Muni (with a lot of effort) can run a fleet of trams that are 70–100 years old. They've modernized the propulsion where necessary and made whatever other changes were needed for compatibility. Part of the reason that's possible is that Muni runs a 600 volt system which is common worldwide (although largely supplanted by 750 volt setups). These antiques run in revenue and charter service all over the city and yet BART can't find windows for its cars that were built to its specifications.
BART ordered brand new bespoke trains from Bombardier and still uses a bespoke traction system (1000 V DC). Factor in BART's one-off driverless cable car and their standard gauge diesel line. In 15 years when stuff starts wearing out, which agency do you think is going to have a more difficult time with procurement and maintenance?
Caltrain is "heavy" rail, sure. Muni isn't. When they were new the PCCs were used globally (including in San Francisco) and serve as the basis for a number of modern designs. BART set out to be the sexy anti-rail and that's the problem. Fifty years on and they've doubled down on bespoke gadgetry.
Standard gauge rail still has several advantages: first, I imagine at least for the wheelsets and the bogeys they could use standard parts; second, even if you can't use standard train cars in the subway, you can use train tracks to move your cars - the Munich subway does this often, e.g. this article is about trains being shuttled several hundred kilometers to be retrofitted with a fire extinguishing system (https://www.u-bahn-muenchen.de/blog/2022/03/b-wagen-auf-gros... - of course you can't do that with light rail vehicles, the cars have to be built to comply with railway standards).
From what I've read (I think there was discussion on HN about it a few months ago?), it's not only the gauge. The entire system was a 'clean sheet' design, made by aerospace engineers. Everything is totally different from what you'd expect in any normal (heavy, light, subway) train.
BART was designed by aerospace engineers. They wanted to minimize weight. In order for the light-weight cars to not tip over in windy conditions they needed a broader gauge.
I always heard it was an attempt to keep anyone using the rail for carrying cargo or other comercial traffic. They had concerns folks would sabotage their growth in order to resell the lines later.
You can take a ferry and then SMART all the way to San Bruno (I think they are planning an extension to Cloverdale, and eventually to Fort Ross). Personally I would rather want faster muni buses to the Avenues (or even the Persido) over BART to Marin, although People living there might disagree.
Technically yes, in practice not really, unless you're proposing a ridiculously wide gauge (several meters, or something like that!).
Even standard gauge trams have no difficulties navigating curves that are much tighter (25 m, down to 10-ish m on some legacy systems) than anything you'd seriously consider when building on a new rapid transit type rail system (normally at the very least a three-digit metre figure, ideally something more like 200 or 300 m).
The only thing that directly scales with the track gauge is the length difference between the outer and inner rail in a curve and the minimum radius down to which the self-steering effect of conical wheels can still compensate this length difference. This means that with a larger track gauge you might get a little more wear and tear for the same curve radius, but a moderate widening of track gauge (e.g. BART is approx. 16 % wider than standard gauge) will equally not cause a dramatic effect here.
In the best case, with standard gauge self-steering might work down to 150 m, which in the case of BART's track gauge would turn into 175 m, which is still rather on the tight side for a rapid transit-style line (and as originally built, BART didn't use conical wheels anyway, so they didn't benefit from self steering in curves regardless of radius used).
The bigger factor in terms of curve radii is the length of your vehicles, how much vehicle throw you're prepared to accept in tight curves, and possibly whether you want to have trains with open gangways, so passengers are able to move between individual vehicles.
Besides India and neighboring countries, it's also used in Argentina and Chile, and the difference to the gauge used in Spain and Portugal is negligible in practice (only 8 mm): https://en.wikipedia.org/wiki/5_ft_6_in_gauge_railway. Not sure if people in Argentina or Chile would say they are using "Indian gauge" though...
> Not sure if people in Argentina or Chile would say they are using "Indian gauge" though...
Unless they are a train geek they wouldn't say that, and probably wouldn't even know it. To people into trains it is known as Indian broad gauge, but most people won't know about such details, nor do they have reason to care. Though I would hope the operators know this - it makes it easier to order trains when you can use the industry terms.
This crash caused the entire system to be disrupted for hours, even very far away from the crash. According to BART, "We don’t have extra tracks to maneuver around problems. That’s why our system comes to a halt from one incident."
"We shared the info [of an early report of someone being on the tracks] and some took to twitter declaring that the person was a junkie on our tracks and it is BART's fault.
We hope you have all since deleted your tweets."
I am looking forward to the future of aggressive-aggressive tweeting from public transit agencies.
I've also always wondered if there was any way to help BART, sort of in a USDS style, or if the problems really are paltry budgets and mismanagement, and so joining in an engineering capacity wouldn't help at all.
My POV is that it's mostly corruption. They have plenty of money but are set up in service of the employee unions and bosses, not the riders or cities they service. Bart employees make obscene salaries and the system is very protective of their monopoly.
Every major public transit system in the world has employee unions and most of those systems are a lot nicer than BART.
The problem is that the United States is not good at building this sort of transit, and it's going to suck no matter how much money we spend and how much we pay the employees because the systems are not well designed or maintained.
In most countries the union is reasonable to work with. For that matter in most counties management is reasonable to work with. In the us neither cares for anything but making themselves better at their expense of anything else.
In my limited experience with transit districts, they don't recruit high performers. It's a hang-out type of career, and they hire people like them.
As far as mechanics keeping older machines running, what is described in the article is typical. It is old and is being replaced. Giving mechanics MS Win 11 to download log files via a recent OS doesn't improve the outcome.
Feels pretty circular. It’s not the unions and it’s not the money. It’s the design and maintenance! Okay, but why would that be uniquely bad in America?
The MTA in NYC spends about $19 billion per year. It’s hard to fathom that amount of spend, and equally hard to imagine how residents get so little for so much.
Bart station attendants make over 3x the median rider. They do nothing but sit in the booth. They don't sell tickets or monitor fare evasion, and they are infamously unhelpful at answering questions.
> Bart station attendants make over 3x the median rider.
which job title specifically are you referring to? from the pay schedule linked above, the closest thing I see is Station Agent, with a pay range of $73-86k.
and where are you getting the data on the median salary of a BART rider?
BART claims says their median rider makes 50k, based on a survey they conducted in 2020. You can find various sources by searching "rider profile" or something like that.
I downloaded the results from that page, loaded them into a spreadsheet, and less than 25% are earning more than 150k/year and only 17% are higher than the 160k median income.
All these involve overtime which means:
- lower quality of life
- either not having kids or having to hire someone to take care of them
There is definitely something wrong if the system allow people to only take a handful of days off a year, is there a hiring freeze or something? Any sane manager would prefer having more workers that rest fully and stay motivated than people extending their times and becoming fatigued, demotivated and grumpy in the process.
Where did you get the median income from? Also, median household income is different from median income. According to the last census, median household income in San Francisco is under $120k[1]. That is household. The average income for a person is less than $82k[2]. Oakland and San Jose are lower than that.
What I mean by "corruption" is
that the compensation in the story you shared is from 2018, and it's still going on in 2021 (the compensation data I shared)
They were paid slightly more than enough to afford average rent for an average unit in San Francisco. They earned it by working overtime. By working more than full time and being compensated according to their employment agreement. The idea that that’s corruption is mind boggling to me. I don’t know whether you just want janitors to be underclass by definition or whether you object to people being compensated for their work, or what could possibly be the problem here.
Personally, I think everyone should be able to afford to live comfortably wherever they are. And I think janitors and other people who do often thankless and grueling work should be compensated substantially more than they are, not less. If it were up to me, no one would have to work overtime to afford average rent where they work so hard already.
It's over double area median income. It's simply not the case that it's just enough to survive or anything like that. Those people could afford to live almost anywhere in the bay area easily.
The part that makes it corruption is that BART is overpaying to pad the pockets of specific more senior members of the union at the expense of less senior members and the public.
To make it concrete, I have a very nice and spacious apartment in a good location in SF. Around 85% of BART employees could easily afford my apartment, based on public data (less than 30% one month pay).
believe it or not, BART is actually competent and does what they can with the cards they have been dealt. name another US transit agency implementing a takt
BART discovered conical instead of cylindrical wheels in 2018[1]. This is dawn-of-railroad technology. You can accuse BART of many things, but competency is not one of them.
The old wheels were cylindrical but the rails were tapered to provide self-centering. This works well for straight track and large radius-curves. The trouble with conical wheels is that too much self-centering can induce sideways oscillation at high speeds. BART was designed for 80MPH, a high speed for the time and still fast for a transit system. BART was also the first rail system to have active suspension. Rail geometry, wheel geometry, and suspension all interact.
High speed rail wheel and track profiles are a complicated problem. The Shinkansen system in Japan did a lot of work on this, as did the TGV developers in France.
It took a while to get wheels, rails, and suspension to all work together well enough for high speeds. Now this is reasonably well understood, but it wasn't when BART was designed.
Now this is reasonably well understood, but it wasn't when BART was designed
Claiming that BART was ground breaking and could've never predicted the consequences of their design choices is quite revisionist. They got called out for their dangerous train control almost immediately. 80 MPH is not and was not high speed. Amtrak trainsets were cable of over 100 MPH back in the mid-70s. BART just reinvented everything poorly (that's their MO).
Anyways here's a technical piece about BART wheels:
With trued wheels and smooth ground rail on ballast and ties, BART is one of
the quietest vehicles. in operation at U.S. transit systems.
Problem is BART is exceptionally hard on their track. Even with conical wheels you can feel the new trains bounce up and down on wildly out of round wheels. You can feel the rumbling on the decrepit track between Lake Merritt and 19th St. Normal railways often lubricate their tracks, but BART can't. Normal railways increase the track gauge slightly in curves (because most train cars don't use differentials), BART pretty much doesn't.
This was my favorite bit:
Of these two types of curving noise, wheel squeal is the more prevalent,
while wheel howl may be limited to lightly damped aluminum centered wheels
such as used at BART. In fact, wheel howl may be unique to BART, because
BART is the only transit system employing rigid aluminum centered wheels.
> Normal railways increase the track gauge slightly in curves (because most train cars don't use differentials)
Actually gauge widening in curves is to some extent probably more a remnant of steam locomotives with their comparatively ginormous wheelbases.
Based on current knowledge, a slight gauge widening on straight track and a slight gauge tightening on tight curves might actually be more beneficial – while trains don't have differentials, they normally (BART and some streetcar systems excepted) use conical wheels, which can self-steer themselves around curves down to a certain radius. That radius is somewhere in the range of a few hundred metres, but its exact value depends on the equivalent conicity of the combination of wheel and rail profiles.
A higher equivalent conicity reduces the minimum radius down to which self-steering remains effective, while a lower conicity reduces hunting and increases stability at high speeds on straight track. Simultaneously, given a nominal track gauge, a slight increase in the track gauge reduces the equivalent conicity, while a decrease of the track gauge noticeably increases equivalent conicity.
Based on current knowledge, a slight gauge widening on straight track and
a slight gauge tightening on tight curves might actually be more beneficial –
while trains don't have differentials, they normally (BART and some streetcar
systems excepted) use conical wheels
Right, BART got the track gauge wrong when they were using flat wheels. Instead of self-centering the wheels got dragged down the track. This went on for forty-odd years which is how BART earned its reputation for being so damn noisy.
> Now this is reasonably well understood, but it wasn't when BART was designed.
absolute nonsense.
nevermind that the shinkansen opened a decade before BART, the pioneer zephyr hit 112 mph in _1934_. while the dynamics of the wheel-rail system are complex and still the subject of active research, the need for conical wheel profiles was well-known when BART was designed. the choice of cylindrical wheel profiles was purely a symptom of not-invented-here syndrome, and BART being designed by aerospace engineers. the best excuse they could come up with for that decision is, uh, muni did it first.
... uhh, your own link says otherwise, emphasis mine...
>To answer the question, the original BART wheel profile, you can consider it like a cylindrical section of pipe. While the new profile is tapered, like a curved barrel, if you could imagine that the cylinder shape pipe rolling down a slight incline it really just wants to go straight. It doesn’t want to turn to the left, it doesn’t want to turn to the right, it just wants to go straight. That’s what our original BART wheel is like. Whenever it would come to a turn the wheel flange is what makes that wheel turn and go around the curve and that results in a lot of extra wear. The new wheel shape that we call the BT-3 Wheel Profile tends to want to self-center between the rails and it even steers in the turns so the result is much less wear and noticeably less noise.
That doesn’t seem to be a charitable reading and in any case it has to do with wheel taper, more like cone than cylinder. More specifically the nature of the solution was getting two parts of the org, track and train, to work together. While that may seem elementary stuff, anyone at a big org can attest to how often it is tremendously difficult to do sometimes.
I write this not as an apologist for commuter rail, which I find excessively expensive and inflexible outside of very circumstances, but as an excuse to link to the lovely Feynman description of why train wheels are tapered:
?? This is a 2018 piece describing how they moved from cylindrical wheels to an advanced wheel profile. I don't think they're claiming the new, non-cylindrical profile is particularly advanced, either, but just carefully optimized to maintain a single point of contact even as the wheel wears.
like i said, they do what they can with the cards that they were dealt. the initial design of the system was flawed in many ways, one of them being the cylindrical wheel profile
Without this blackmail power over the region, BART'a costs would be considerably lower. Assuming 1/3 lower, we'd get 50% more BART for our money, and I think that would be much better than keeping a few thousand union members in nice lifestyles.
So you're saying BART employees are providing a vital job serving critical infrastructure? Sounds like the kind of worker you'd want to make sure gets decent pay and working conditions then.
"Without leverage workers wouldn't be able to negotiate better salaries" is hardly a novel idea. The top 10% of people in software development (hint: if you're on HN, you're probably in that 10%) can usually rely on market demand as leverage for the time being. For everyone else the best chance at gaining leverage is collective bargaining. Seems like it's working quite well for BART employees.
> our money
What percentage of your income goes to BART? What percentage of your income goes to militarizing the police and to the prison industrial complex? What percentage of your income goes to the military industrial complex? What percentage of your income goes towards rent? What percentage of your total compensation goes towards health insurance? What percentage of your delivered value goes towards your employer?
If you're upset about not getting your worth it feels like there are a lot bigger drains siphoning off that surplus value than BART. Seems odd to get so upset about BART salaries when their work seems to be vital enough that refusing to work can "paralyze the entire Bay Area".
You don't seem to be interested in providing arguments to give weight to your opinion that BART employees are overpaid, so your assessment reeks of projection. I don't even live in the US, let alone the Bay Area.
Oh yeah, the problem with BART is employee wages, look at all those millionaire stall clerks and attendants, they're what's holding back mass transit in the bay area - unlike in Europe, where public transit works so much better because there are no unions and no strikes anywhere... </sarcasm>
I think it's not as crazy as it sounds. You should visit SF and ride BART. You'll likely find the experience horrifying as a direct result of the behavior of these highly paid employees. The badness of the BART experience is a major cause of underinvestment. The public simply does not want more of that.
Caltrain also has limited ability to route around accidents, and in some cases has to run trains the "wrong way" on the other side of the tracks to get past certain areas.
They also have no communication at all. Back when I had a Caltrain commute I would use Twitter to find out if there were accidents or delays, because the station signs were alway wrong and almost all of the stations are unstaffed. I would see posts on Twitter from people who were on a train that crashed into a car and the station signs would still say everything was on schedule.
Caltrain is basically an afterthought. Secondhand rolling stock, tracks shared with freight, and perpetually starved for funding. BART was a green field transit system. BART had every opportunity to design redundancy into the system and didn't. And yet Caltrain actually has dedicated passing tracks while BART doesn't.
> For example two days ago there was a horrific final-destination-esque crash in which a motorcyclist happened to be in front of the train.
Isn't Bart entirely grade-separated?
But yes, no ability to single-track is an issue.
The non-standard rail gauge is also an ongoing issue. Everything has to be custom. Compare this to Caltrain. Several years ago, they wanted to add capacity. They bought off-the-shelf Bombardier cars from an agency in Socal. I'm not sure if they ever even painted them, but they could use them almost immediately.
Yes, but portions run near/under/over/alongside/in the median of roadway traffic. If you read the tweet thread you can see that a driver on the road was ejected into the BART ROW and was hit by a train.
> But yes, no ability to single-track is an issue.
Though it's not an absolute panacea, either. The Washington subway has crossovers every two to three stations and is set up for bi-directional operation on one track, and the two things I immediately noticed when I visited Washington eight or so years ago were:
- service levels on weekends were already only meh even without construction works
- there were construction works on a very small segment of the Red Line between two of those aforementioned crossovers – those works only required closing one track, so they decided to continue running a service on the remaining track. Unfortunately single-tracking severely limits the number of trains you can run, so that tiny closure meant that on that weekend the whole length of the Red Line (all 32 miles of it!) was only operating every 20 minutes or so (originally I had considered an accommodation along the Red Line, luckily I had reconsidered and chosen a different place to stay even before learning about those construction works).
After some googling, it seemed that this (i.e. construction works on a tiny stretch of track significantly affecting the service of the whole line even during the daytime, at least at weekends) was not an uncommon occurrence in Washington.
While single-tracking might be no problem late at night (when a reduced frequency doesn't matter that much, and might not be even all that much reduced as compared to normal service levels at that time of the day), or during unplanned short-term disruptions, for that kind of scheduled-in-advance all-day construction works I'd say it's at least debatable whether a complete closure of the affected stretch of track (with a bus replacement service) and a full service on the whole rest of the line might not be a better compromise…
IIRC that's also why the hours of BART are so limited. They have to do all their maintenance when the train isn't running since they can't route around it
No. BART tracks pass under the street at this point. This motorcyclist managed to fling himself over a prison-style fence while operating on a street with a posted 20 MPH limit.
It's almost like the people in charge aren't really affected by it, and therefore don't really want to put any focus and effort (money, time, attention) in to making it a bit more reliable and attractive.
In companies, the feedback loop is shorter. If the company's products or services are disappointing, the sales will fall (unless the company happens to be monopoly, but that's a different point), which will immediately be noticed by the CEO, who will start some mitigating actions that is likely to put some pressure on the workers. Whereas, if people are unhappy with a public service, they can do... what exactly? Swap Republicans for Democrats (or the other way around, depending on who's in power right now) in the next election? How likely is that to accomplish anything?
What are you talking about? The "Fleet of the Future" (or Deloreans, as I call them) now comprises a third of the cars in operation. The older cars (space shuttles) are being phased out.
Windows 98? The DLR (Docklands Light Railway) still uses computers from the 80s for their self driving and signalling systems. They have a room full of them and when the last one dies, that's it.
London Underground were at one point the worlds largest manufacturer of vacuum tubes for their signal systems (can't buy them, I guess we have to build them)
Train systems are one of the ultimate examples of people not thinking long term, complex systems and infrastructure that cannot be closed even for a few days. So you often get these weird special cases.
True, but once those machines are gone, they're fucked. Plus anyone having issues with Win98 is doing a lot worse than DLR.
Real long term thinking would be a modular signalling system where you could reliably replace one section in (say) 48h, so you could close for a weekend and reliably re-open with whatever tech we will be using in 2070 in place.
I might be a bit jaded on this. I spent about 8 years nursing these systems to keep them working because there was no way we could close a TfL line for 3 months and completely change the signalling system and make it faster, safer, more reliable, self driving etc. Even having moved to finance, I am routinely delayed on the way to work when the (new) CrossRail signalling system conflicts with the (old) system on the same line for different trains.
C'est la vie I guess, I understand discounting so basically anything that takes 40 years to be useful is NOT worth doing...
I hope so. The difference between the old cars and the new ones is striking enough that I've noticed myself holding my breath waiting to see which I'm about to get in.
I fear it won't take long for the new ones to degenerate, though; I've even noticed some signs of that already.
Its puzzling how the world's richest country spends more than a country like South Korea on public transit and still stuck using Windows 98 and other ancient antics.
For instance the Seoul Metro yearly budget is 10x less than New York's yet it runs far longer and more efficient. It's also safer.
when something needs to run day-in and day-out every day, it is difficult to justify swapping things just because they're old.
as it turns out, old things have stood the test of time and generally work quite well.
vancouver bc upgraded its own train control systems a handful of years ago. unsurprising to anyone who has tried to do a migration, there were service incidents. trains stuck in the middle of nowhere sort of thing.
It's all done, upgraded, and modernized yet. But there is a growing pain and growing cost. The tricky thing to know is when the juice is worth the squeeze.
Not to mention the amount of similarities between SkyTrain and BART with the automated system and custom parts. It didn't even strike me as odd that the trains didn't have drivers until a dump of snow hit the rails and someone had to open the front compartment of the train to access the manual controls to drive it into Columbia Station (why is it always Columbia?)
The decline of BART and Metro is a good metaphor for the decline of American government competence. The 1970s saw a wave of state of the art automated train systems built in SF, DC, and ATL. When we moved to DC in 1989 the Metro offered a smooth, comfortable, computer-controlled ride.
Today those systems are in shambles. The automatic train control infrastructure in the DC metro has deteriorated so much that it was turned off in 2009. Today a DC Metro ride is uncivilized, like the ancient system in NYC, with some poorly trained driver jerking you to a stop at each platform. Not only that, but the 6 minute headways built into the original system were relaxed to 8 minutes, and even that is not achieved in practice.
This is quite the exaggeration. I use the DC metro multiple times a week (but no longer daily). I also prefer to use public transit while traveling. The ride is similar to elsewhere in the US and about 50% of abroad systems.
As someone who did IT at a public transit agency for a medium sized city briefly, this is all pretty accurate and similar at most public transit agencies. Even brand new busses are still using old hardware under the hood that requires special deutsch to serial cables that require windows 7 machines to interface.
Likewise all the software that runs transit agencies is extremely dated and heavy.
Reminds me of the McLaren F1 sports car - a bespoke once off run V12 BMW engine so it uses a custom McLaren developed PCMCIA adapter as the main diagnostic interface.
Interface and software only works with a Compaq LTE 5280.
If they depend on direct hardware access, there are other operating systems that can do that. And if they can do multi-tasking, they can switch to pretty much any other operating system.
But in this case I bet it's a combination of them not actually having any option other than to comply with the requirements of some old piece of software that is outside of their control. If they were to demand that all software used in those systems were delivered with sources and compilers, they could at least maintain it and port to newer operating systems and hardware. But they don't.
The article mentions they don't need DOS anymore, so they seem to be past that particular problem. It could have been as simple as something like FreeDOS on modern hardware didn't work because it was written to use a real serial port and not something like a USB to serial adapter. And perhaps until recently, they didn't have anyone to help figure out how to bridge something like that through an emulator or vm passthrough device, etc.
BART is the ailing infrastructure / life support before self-driving cars come online, and that should be immensely respected.
We should always remember where we came from.
Autonomous vehicles are not a replacement for intra-regional transport systems like BART, they're complementary last-mile transport competing against things like taxis.
The relative costs make the difference obvious. A one way BART ticket between two distant stops like Dublin and 16th st/Mission is currently $3.45. Using a conservative cost-per-mile figure of $0.50 for the car and ignoring the bridge toll, the 37 road miles between those stations would cost over 5x more than the BART fare. An expensive autonomous vehicle that has to recoup R&D and generally be profitable would probably have to be an order of magnitude or more expensive than BART.
Given the costs for development of roads has already been paid for, self-driving cars are actually incredibly cheap.
It’s the cost of electricity plus amortized depreciation of the vehicle. R&D is pretty even I think when you consider the development costs that also went into engineering the BART system.
The cost per mile is definitely within the range of ~.09 ($3.45 / 37 miles), with immense value from being able to travel anywhere that has roads and been geo-mapped. One of the primary limitations of public transport is that it’s limited to specific locations. Self-driving removes that constraint.
$0.09 is more like the cost of energy than the total cost including depreciation. The federal $0.50 rate is much closer to the actual targets companies are aiming for.
The federal reimbursement/tax deduction rate doesn't incorporate the "labor costs" of driving either. Depreciation is usually the main component in both.
The other factor is that roads simply cannot handle the volume of people that trains can. One subway train can easily result in hundreds of cars not being on the road.
Same goes for parking, especially in cities like San Francisco. (And if someone wants to counterargue that self-driving cars can drive away to park somewhere else -- that just makes the traffic even worse, since now there's twice as many cars entering and leaving the city around rush hour.)
I saw a transportation guy that said what transit systems like BART are good at is getting people on and off quickly. Better than buses and far better than taxi's.
>Using a conservative cost-per-mile figure of $0.50 for the car and ignoring the bridge toll, the 37 road miles between those stations would cost over 5x more than the BART fare
Do note that the BART fare is heavily subsidized, actual costs[0] are closer to .40cents per passenger mile. So Bart is only slightly cheaper, by lets say 25cents per mile[1], than a car which is much faster, cleaner, serves a larger geographic area, and is far more convenient.
You must be taking different Bay Area transit than me (not that Bay area roads aren't hellish). Other than peak commute times cars are far faster to pretty everywhere BART serves outside of SF proper, and obviously much faster to anyplace BART doesn't.
The aforementioned Dublin > mission BART route is only about parity with driving for a 9:00am arrival in SF, and much slower after[0]. To say nothing of the obvious choke point that is the bay bridge, which would be well served by either an expansion or a hybrid approach. Robotaxi to west Oakland, hope on a bart, pick up a new robotaxi in SF to get to e.g. the sunset, or other not-bart served location.
cars are not a replacement for trains, period, full stop. autonomous operation does not change the fundamental math.
a single BART train car carries 50 people seated, up to 200 people when packed nuts-to-butts. the longest trains are 10 cars [0]. so at rush hour, you'd expect 500-2000 people per train.
say we replace one single train with autonomous cars. that means the roads surrounding the subway station now have an additional 500-2000 cars, beyond the existing traffic of rush hour. and they're all trying to navigate to a curb lane so they can pick up or drop off their passenger safely.
if your trains are running 10 minute headways, that means in order to compete, those 500-2000 autonomous cars have 10 minutes to clear the area around the station, and at the same time another group of 500-2000 cars needs to come in, in order to pick up or drop off the next trainload.
the math simply doesn't work. even if a genie granted you three wishes and you used all of them on having cars that are perfect, absolutely bug-free, incredibly smart, 100% autonomous in all driving conditions, there is no way to match the density of people movement that trains allow.
your original statement was that self-driving cars would replace systems like BART that operate in dense urban areas. now it seems like you're moving the goalposts to talk about rural areas.
> except in major population centers
80% of the US population lives in what the Census considers an urban area [0]
for the remaining 20% in rural areas...I don't think anyone would argue that subway trains are the ideal mode of transport for them.
but at the same time, I don't think the "shared fleet of autonomous robo-taxis" model is the right fit for rural areas either. if I lived in a rural area, I'd want to have a vehicle I owned in my driveway, ready to go whenever I needed it. it may have some autonomous features, but I would have no interest in any of the "have your car make money while you sleep" [1] programs that autonomous car companies have proposed.
if your concern is promoting transportation methods that are useful and effective across rural, suburban, and urban areas, the best example of that that I'm aware of is the humble bicycle. are you in favor of improving bicycle infrastructure as well, such as by building more protected bike lanes, tax credits for e-bikes, etc? that is in many ways not as "sexy" as autonomous cars, but that's because it's a boring, proven technology that could easily be implemented in a wide variety of jurisdictions.
According to the census, I'm in an urban area. And it is true, I can walk to a grocery store, but there will likely not be much transit here at all, since the population total is about 8000.
A town of 8000 definitely warrants a bus line or two. In addition to inter city buses to nearby towns and cities.
I live in what I consider a rural American town, 10,000 people spread around 200 km² (but US census still considers it urban (!) so you are right about that) and still we get regular bus service from 2 lines and a couple of ferry lines to nearby cities.
But to raise the point of your parent home, we do have a car in our driveway ready for our convenience, but a bicycle is actually way handy (especially when coming home from the bar) and then the bus is actually very well used, and has been increasing in frequency over the past decade. It is simply way more convenient to ride the bus to the ferry then drive during commuter hours.
Yeah, I find that transit in these smaller towns really depends on the towns around (you have a ferry to get to, we have various other smallish towns each about 15 - 20 minutes away).
The town itself is very bikeable, walkable even (an hour or so will get you literally from any point to any point), but connections to other towns might be interesting (the only thing we have is a public ride service for elderly/disabled, though others can use it without the subsidy) - it's a glorified taxi.
