The soft glow of electric sex gleaming in the station

Jackson Square

Roving UHub photographer Jed Hresko checked in tonight from the Jackson Square stop on the Orange Line, where CharlieMachines stayed up even as the lights went down.

Neighborhoods: 

Topics: 

Free tagging: 

Comments

Was there a power problem in

Was there a power problem in the area or were the lights just out?

I'm only asking because Im not surprised if there was a power failure that the charlie system would work. Not only because the T doesn't really run off the local power grid (it gets its power from Mirant, not NStar/Nat'l Grid), but since the charlie system all computer based, power failure without proper shutdown can really cause problems, so I'm sure those things are on UPS's at least. Of course we all know how hardware on the T is such a delicate flower, even someone blowing on the terminals might make them spontaneously crash, so battery backup power is a must!

Not really

but since the charlie system all computer based, power failure without proper shutdown can really cause problems

That doesn't follow. Problems with sudden shutoff come from cached data in ephemeral storage that isn't properly stored to something more persistent, leaving the system in an inconsistent state. But that presumes there is some data that needs to be stored.

If so, this is a problem that has been safely tackled for decades. Even your typical consumer device nowadays typically uses some sort of journalling filesystem for everything, making it always capable of rolling back to a safe state, even after a power failure. Presumably the protocol that the Charlie system uses has similar provisions.

Of course, this IS the MBTA we're talking about so, yeah...

Windows

I work with Microsoft Windows all day long and have done so since the early 90s :) The Charlie card system is all Windows based. It's also the T.... Just sayin..

Even so

Even so, these are DB transactions, filesystems shouldn't even be part of the discussion here. If they are Windows-based, it's likely Windows Embedded, and the entire system partition is protected and for all intents and purposes read-only. You don't need a writeable host system to make DB transactions.

From anecdotal observation, there should be 1.5 round trips on a transaction. You scan a card or ticket. The system processes the ticket information remotely, determines what the new last-value should be on the card and whether or not the current entry request is valid. Send the info back, the reader updates the cached info on the card/ticket and if allowed, admits the patron, and then sends the success message back to the database.

If the success response isn't received, then the account isn't debited (assuming it was a value deduction), because you don't know if the gate failed or not and you don't want to double-charge patrons (yes yes, we know this happens). The gate doesn't need to receive an acknowledgement of the success, it just needs to know that the transaction was OK, prepare to open of the gate, and write the card. The reason it should be in that order (authorize the gate and then update the card) is because if there's a gate failure, the card's last-update and last-amount fields shouldn't be updated because that locks the patron into the gate delay to prevent card-sharing.

And anyway, card-sharing is a problem that should have a legal solution, not a technical one. There aren't really any good technical solutions for the problem that are also good at exception handling. Treat it like fare evasion (since it is) and just monitor/enforce it.

I like how we have one of the best technical schools in the world right here, and yet we got to choose between two utterly incompetent assholes for the Charlie system.

Distributed database

I wouldn't expect the front end terminals to have persistent storage either (but again... this is the T). I think it's reasonable to expect the fare vending machines to maintain a database link with headquarters (or else go out of service); but I don't think that the mobile fare deducting/checking machines have that kind of guarantee. There's just too many cases where wireless data links would time-out, causing too many delays at the fare-boxes.

I haven't really looked into the MIFARE system, so this is speculation. But you could design a fare-card system with the philosophy of "trust-but-verify" and it would not require constant contact with a central database, making it much more robust. I imagine this is what they did.

The Charlie Card or Ticket needs to keep track of the remaining account balance or pass status on its storage medium (flash or magnetic stripe). If that was all, then it would be easily spoofable with no hope of detection. I know some folks at MIT demonstrated that. The way you detect fraud is to store transactions locally on each fare-box with some unique identifier, and then reconcile the transactions at the end of the day when finally linked up to the central database. Then that information can be distributed back out to all the fare-boxes, so they know what every Charlie Card or Ticket should show the next time encountered when out and about. This is also a way to distribute information about online-added value and purchased passes, which always takes a day to promulgate.

Storing the transactions safely on each fare-box would take some care to avoid inconsistency in the case of power failure. But this is a technique that's been studied and mastered for decades. There would also arise flaws or missing transactions, inevitably. The system would have to handle that gracefully, minimizing the probability of screwing someone over. Getting the details of this system worked out is complicated, but that's why we paid them a hundred million bucks, right?! Bleh.

Storage systems

The geeks come out of the woodwork... ;-) Seems like Matthew deals with storage systems a bit.

As I'm sure Matthew knows, more sophisticated storage systems have their own battery power just for this situation. Separate from the OS, the battery power allows the storage system to harden the data from cache onto disk so that it is in fact saved. This can take a number of minutes, depending on the size of the storage system, and the battery power has to be designed to provide power long enough to harden the data in a worst-case scenario.

I have no idea what the T has for storage systems.

Sorry for geeking out.

Revenue source?

That photo screams "casino" to me. I don't suppose the (T) could turn itself into a distributed casino, running the Charlie maSheens as video poker kiosks as well as fare kiosks. Would certainly give folks something to do while the trains are delayed. And would also provide much needed revenue for the system.

Hey, you can buy lottery tickets in most subway stations, can't you?

Ok, there might be some issues with folks who actually want to buy a fare being blocked by the slot zombies. Hell, they can probably make enough from the machines that the trains can be free.

Not

Not. Please, The T can't even manage the money it makes now :)

But seriously, I could see people line up at these like slot machines before going thru the gates. Depending on what came up, depended on if the rider was going to have a sucky commute or not.

*pulls handle*
BING...BING....BING
"Three Limes - Your Prize: Stuck on dead train on the Green Line between Copley and Hynes"

*pulls handle*
BING...BING....BING
"Three Buses - Your Prize: Bus driver pulls away just as you run up and now you have to wait a 45 minute headway for the next one"

*pulls handle*
BING...BING....BING
*alarm sound*
"JACKPOT WINNER - Three T tokens - Your Prize: Police Action at your destination station, do not pass go, do not collect 200 dollars, and head toward the sea of people waiting for shuttle bus"