Advertisement
Distance driven today: 284 miles / 457 km
Cumulative distance driven: 1,703 miles / 2,741 km
Today’s trip: Fort St. John, British Columbia, Canada to Prince George, British Columbia, Canada
Hours of sunshine during the ride: 5 ;-)
Today’s ride was pretty uneventful, apart from a pesky problem with the onboard system monitoring the brakes of the motorcycle. About one hour into the ride, the warning system on the control panel, keeping track of the health of the brakes, started flashing. It indicated that there was a “brake failure”. I immediately stopped to trouble shoot, but nothing that I could come up with helped me figure out what was causing the error message, or how to make it go away.
I tried turning off and on the ignition key, pumping the front and rear brake, taking out and putting back in one of the fuses, reading the manual, but none of that helped. I tried riding for a while and braking hard, but that did not make the warning message go away. As somebody who has worked on several large software projects in my career, and who has specialized in human-computer interaction, I figured
that this really can’t be that complicated. Or could it? I knew that there is software in the control unit onboard the motorcycle, monitoring a number of different systems. Could this perhaps be an unusual software bug in the BMW onboard monitoring software? I mean, the brakes looked all normal to me, and I for once could not detect a “failure”. Should I trust the warning message, or should I trust my own sense? But I also know that the onboard software is not anywhere near as sophisticated as my iPhone, o for that matter as the netbook computer that I carry with me on this trip. So what to do?
I continued riding for a few minutes, and started mentally to go through all possible root causes. And as usual in these situations, the most likely solution is typically also the simplest one. So I took a step back and reexamined the situation. Could there be a simple explanation here? I knew that there is a sensor attached to the front left fork, reading the revolutions of the front left brake disc. The purpose of the sensor is to monitor that the front wheel does not lock if
the brake is applied with force, such that the wheel locks. Needless to say that, should you brake hard enough to lock the front wheel on a motorcycle, well, you are very soon going to be seeing the road too up close to be comfortable. In other words, the sensor is an Anti-Block System sensor, also commonly referred to as ABS, ensuring that the wheel never locks, no matter how hard you brake.
I stopped the bike, and got on my knees and looked closely at the ABS sensor. And there I found the bug. No, it wasn’t a software bug, but rather a collection of physical bugs (bees, flies etc.) that had decided to commit collective suicide and find their final resting placing on the surface of the actual ABS sensor. The impact of their crushing death, when they hit the sensor at 70 mph (110km/h), had simply crated a blocking membrane of gooey stuff on the surface of the sensor, which now sent an error signal to the onboard monitoring system! With a delicate swipe of the sensor with my glove, the bug issue was fixed. It is fair to say that, in this situation, a physical bug caused a virtual software bug. In this case, the solution was easy (once I figured out the problem was that is) and I was never in danger.
However, there are other cases where an erroneous sensor feeding misinformation to the operator, can lead to catastrophic outcomes. That was the unfortunate route cause of the downing of Air France, flight 447, in the summer of 2009, over the Atlantic Ocean on its way from Brazil to France. A simple temporary blockage of a sensor, fed erroneous information to the pilots, who in their turn acted upon that misinformation. Within 10 minutes, a perfectly normal flight onboard the Airbus 330, which is one of the most sophisticated airplanes in the world, crashed in the Atlantic Ocean. And it all started with a simple misreading of a blocked sensor. It’s worth keeping in mind how much we rely, on a daily basis, on automation, electronics and our interaction with these components and the information they give us.
And with this modern example of human-computer interaction, which is my professional passion on a daily basis at work at Amazon Kindle digital products, I will end today’s post.
Tomorrow morning, I will be visiting St. Mary’s Catholic school here in Prince George, to see how one middle school class is using the donated Kindle e-readers in their curriculum.
Advertisement
Tot: 0.114s; Tpl: 0.011s; cc: 13; qc: 50; dbt: 0.0619s; 1; m:domysql w:travelblog (10.17.0.13); sld: 1;
; mem: 1.1mb
Mike Lubrecht
non-member comment
It's not a bug, it's a feature!
Excellent job of tracking down your "bug," Christer! If I'd known that you were undertaking this journey, I'd have loaned you my GS911 tool - plugs into the bike's computer output socket, and let's you read all the error codes, etc. on your Smart Phone. Hopefully that will be the last mechanical issue you'll see - Beemers are world class bikes; your ADV should take good care of you and Zoe.