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.
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.
> 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.
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.
1984.
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.
Warms my heart to see that I'm not the only person who's a stickler for this :-)
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?
> 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.
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.
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)
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.
The dysfunction is broader than them being unable to afford engineering talent.
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?
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.
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.
[0]https://mtc.ca.gov/tools-resources/data-tools/monthly-transp...
> 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 :)
I, and almost everyone else here, lack the domain expertise to be of any use in that.
The problem is that BART doesn't employ talented reverse engineers. There is now way they could afford them in that area.
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.
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.
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.
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.'
Besides this sort of thing is well beyond the scope of folks creating subscription based fruit juicers.
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.