Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mars rover Curiosity’s software upgraded

firstpost.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Mars rover Curiosity’s software upgraded

#11

Post by noir_lord »

atsaloli wrote: post #4

A lot of work has gone into making that software especially robust, including some custom tooling for facilitating peer review. Dr. Holzmann (formerly of Bell Labs, birthplace of Unix) heads JPL's Laboratory for Reliable Software to lead this work. If you'd like to learn more, I written about the LARS methodology after hearing Dr. Holzmann at USENIX Hot Topics in Dependable Software: http://www.verticalsysadmin.com/m…

Fascinating, this type of programming has always interested me (as I was a desktop developer who moved to the web) but not something I think I'd want to do (the stress alone must be horrific when you work on any mission critical/safety critical software).

Re: Mars rover Curiosity’s software upgraded

#12

Post by noselasd »

atsaloli wrote: post #4

A lot of work has gone into making that software especially robust, including some custom tooling for facilitating peer review. Dr. Holzmann (formerly of Bell Labs, birthplace of Unix) heads JPL's Laboratory for Reliable Software to lead this work. If you'd like to learn more, I written about the LARS methodology after hearing Dr. Holzmann at USENIX Hot Topics in Dependable Software: http://www.verticalsysadmin.com/m…

Though what you describe covers only the code. The design is just as big a part of the picture and is just as much involved in the verification, revising, reviewing and testing.

Re: Mars rover Curiosity’s software upgraded

#13

Post by nknighthb »

bad_alloc wrote: post #8
aroch wrote: post #3

I get nervous sometimes when flashing ROMs on my phone...And those were downloaded over a (comparatively) 0-latency connection with high throughput. Fact that sending a firmware to Mars is apparently a normal thing now notwithstanding, I find this incredible.

The rover has got two computers though and during upgrades only one is updated. If something goes wrong, the non-updated one takes over and they can restore the last working state. Phones are easy to brick since they lack a backup system.

The ease with which many consumer devices can be bricked by firmware updates is really ridiculous, though. You don't need full hardware redundancy to virtually eliminate them, just a redundant OS partition and a little sane engineering. At that point, any bricking is almost certain to be the result of an actual hardware failure, which is its own problem.

Re: Mars rover Curiosity’s software upgraded

#15

Post by mturmon »

atsaloli wrote: post #4

A lot of work has gone into making that software especially robust, including some custom tooling for facilitating peer review. Dr. Holzmann (formerly of Bell Labs, birthplace of Unix) heads JPL's Laboratory for Reliable Software to lead this work. If you'd like to learn more, I written about the LARS methodology after hearing Dr. Holzmann at USENIX Hot Topics in Dependable Software: http://www.verticalsysadmin.com/m…

And here is some more on Gerard's setup:

http://gerard.holzmann.usesthis.com

Re: Mars rover Curiosity’s software upgraded

#16

Post by jotm »

nknighthb wrote: post #13
bad_alloc wrote: post #8

Earlier quoted context omitted.

The rover has got two computers though and during upgrades only one is updated. If something goes wrong, the non-updated one takes over and they can restore the last working state. Phones are easy to brick since they lack a backup system.

The ease with which many consumer devices can be bricked by firmware updates is really ridiculous, though. You don't need full hardware redundancy to virtually eliminate them, just a redundant OS partition and a little sane engineering. At that point, any bricking is almost certain to be the result of an actual hardware failure, which is its own problem.

I haven't seen an easily brickable device for half a decade now... Android smartphones and tablets are very hard to brick, post-2008 laptops and motherboards have excellent BIOS recovery, what else is there? I bricked an external RAID enclosure by flashing the wrong firmware, but that POS was running on a SiliconImage chip that for some reason allowed flashing a completely different firmware to it...

Re: Mars rover Curiosity’s software upgraded

#17

Post by ams6110 »

johnw wrote: post #5

Also interesting is the amount of damage being done to the wheels as it drives around up there. Some good pictures of that here[1]. Apparently the wheels are designed to leave a mark so they can keep track of the rovers location by looking at the tracks[2]. The tracks spell out JPL in morse code. [1] http://news.discovery.com/space/martian-wear-and-tear-curios... [2] http://www.planetary.org/blogs/emily-lakdawalla/20…

"It appears to be correlated with driving over rougher terrain."

Who'd have thought....

Re: Mars rover Curiosity’s software upgraded

#18

Post by ChuckMcM »

johnw wrote: post #5

Also interesting is the amount of damage being done to the wheels as it drives around up there. Some good pictures of that here[1]. Apparently the wheels are designed to leave a mark so they can keep track of the rovers location by looking at the tracks[2]. The tracks spell out JPL in morse code. [1] http://news.discovery.com/space/martian-wear-and-tear-curios... [2] http://www.planetary.org/blogs/emily-lakdawalla/20…

Thanks for the links, I figured that the lack of compliance in the "tire" section of the wheels would be an issue but that is a bit more damage than I would expect. I am guessing that under some driving conditions you might get up to 50% of the rover weight on a wheel and if that was while the wheel was rolling over a rock, the tendency would be to cut into the aluminium. So one wonders why not titanium outer rims? or a compliance system that would allow the wheel to deform until enough weight had been distributed across enough surface area to keep it under the 'minimal damage' threshold.

Re: Mars rover Curiosity’s software upgraded

#19

Post by nknighthb »

jotm wrote: post #16
nknighthb wrote: post #13

Earlier quoted context omitted.

The ease with which many consumer devices can be bricked by firmware updates is really ridiculous, though. You don't need full hardware redundancy to virtually eliminate them, just a redundant OS partition and a little sane engineering. At that point, any bricking is almost certain to be the result of an actual hardware failure, which is its own problem.

I haven't seen an easily brickable device for half a decade now... Android smartphones and tablets are very hard to brick, post-2008 laptops and motherboards have excellent BIOS recovery, what else is there? I bricked an external RAID enclosure by flashing the wrong firmware, but that POS was running on a SiliconImage chip that for some reason allowed flashing a completely different firmware to it...

Funny, I just saw a friend's Android phone get bricked by an update about two years ago. It was in a state I probably could have recovered it from if its bootloader were unlocked, but it was beyond reach of Joe User.

I've also bricked or seen bricked routers, external HDDs, and TVs in the last five years.

Many TVs, actually, if you include pre-release units. As far as I can tell, most of them rely entirely on testing to avoid bricking devices. They make zero provision for the inevitable case where something goes wrong. Power failures during updates remain a frequent cause of bricking.

Your "exception" is quite a common case when firmware updates are performed manually. Those failures have, of course, dropped dramatically since devices started being able to self-update, but they're far from the only such failures out there. The "some reason" depends on the product and manufacturer, but it's usually a combination of laziness and penny-pinching. Somebody didn't want to do the work, or somebody else didn't want to pay for it to be done.

I've seen the processes that lead to these situations up-close. There are a lot of engineers out there who don't think about failure modes, and a lot of managers who dismiss the engineers who do as paranoid and/or troublemakers.

Re: Mars rover Curiosity’s software upgraded

#20

Post by hnriot »

ams6110 wrote: post #17
johnw wrote: post #5

Also interesting is the amount of damage being done to the wheels as it drives around up there. Some good pictures of that here[1]. Apparently the wheels are designed to leave a mark so they can keep track of the rovers location by looking at the tracks[2]. The tracks spell out JPL in morse code. [1] http://news.discovery.com/space/martian-wear-and-tear-curios... [2] http://www.planetary.org/blogs/emily-lakdawalla/20…

"It appears to be correlated with driving over rougher terrain." Who'd have thought....

When I read the article that also popped out for me.

Unbelievably obvious. Obviously somethings are different in the Martian environment, but the laws of physics didn't just look the other way when they saw the rover coming.

Post reply on HN