Slashdot Mirror


Upgrading Software From 350 Million Miles Away

CWmike writes "Picture doing a remote software upgrade. Now picture doing it when the machine you're upgrading is a robotic rover sitting 350 million miles away, on the surface of Mars. That's what a team of programmers and engineers at NASA are dealing with as they get ready to download a new version of the flight software on the Mars rover Curiosity, which landed safely on the Red Planet earlier this week. 'We need to take a whole series of steps to make that software active. You have to imagine that if something goes wrong with this, it could be the last time you hear from the rover,' said Steve Scandore, a senior flight software engineer at NASA's Jet Propulsion Laboratory. 'It has to work,' he told Computerworld. 'You don't' want to be known as the guy doing the last activity on the rover before you lose contact.'"

62 of 228 comments (clear)

  1. And NASA has made mistakes with this before... by YesIAmAScript · · Score: 4, Interesting

    It is a difficult task. While NASA has don'e a lot better than most of us programmers ever have, they have made mistakes in updating from Earth to Mars before.

    http://en.wikipedia.org/wiki/Mars_Global_Surveyor#Loss_of_contact

    --
    http://lkml.org/lkml/2005/8/20/95
    1. Re:And NASA has made mistakes with this before... by Taco+Cowboy · · Score: 4, Interesting

      That is why I do not understand why the NASA engineers want to take such a risk

      Unless it is a totally fatal software bug - that is, if they do not upgrade the software, the Curiosity rover gonna be bricked - I do not think taking the risk of bricking the rover for a regular software upgrade is worth the danger of bricking the rover, which is, as TFA has stated, 350 millions miles away
       

      --
      Muchas Gracias, Señor Edward Snowden !
    2. Re:And NASA has made mistakes with this before... by Anonymous Coward · · Score: 5, Informative

      99% of brickings are the result of people doing stuff that the manufacturer did not intend for you to do, on devices where important design details were hidden for commercial reasons.

      This is unlikely (one would hope) to be the case here.

    3. Re:And NASA has made mistakes with this before... by hcs_$reboot · · Score: 4, Interesting

      why the NASA engineers want to take such a risk

      Similar to some devices here on Earth, the rover should have an automatic revert solution. For instance, a non-updatable software running on a separate processor detects specific conditions (like no signal from Earth for a while) and flashes back the updatable software to its original version when that condition occurs.

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    4. Re:And NASA has made mistakes with this before... by Jane+Q.+Public · · Score: 4, Interesting

      "I do not think taking the risk of bricking the rover for a regular software upgrade is worth the danger of bricking the rover..."

      I guess it all depends on on (A) what the perceived value of the upgrade is, versus (B) the perceived risk.

      It's probably a safe bet that they learned from the Surveyor issue, and built in better tests and safeguards. I imagine -- although I don't really know -- that they have implemented something like the "rolling upgrades" that are common now, which allow processes to replaced on the fly one at a time, without reboot, and with a failsafe revert that runs at a higher level than any of those processes if anything goes wrong.

      It isn't like Windows, in which just about every time you install or upgrade something you have to make all the changes then "reboot". They get done one at a time, and they are tested individually after they are made.

      It sounds complicated but conceptually it's pretty simple: you have a top-layer monitor program program that accepts commands to replace lower-level processes. All it needs to be pretty "fail-safe" is to wait for a specified period of time for an "okay" signal from Ground Control. If it doesn't receive one in the specified time, it automatically reverts the process back to the old version. It's a little more involved than that, but that's the idea.

      Lots of software does that now. A lot has improved since 1996.

    5. Re:And NASA has made mistakes with this before... by cnettel · · Score: 5, Insightful

      why the NASA engineers want to take such a risk

      Similar to some devices here on Earth, the rover should have an automatic revert solution. For instance, a non-updatable software running on a separate processor detects specific conditions (like no signal from Earth for a while) and flashes back the updatable software to its original version when that condition occurs.

      Such things tend to be present, but how many times have they tested the automatic revert in actual conditions? An alternative codepath is always a risk.

      Updating the software can have great advantages. Only a slightly more reliable connection would allow vast amounts of more science to be done. Adapting the algorithms for autonomous functions such as simple navigation or sample processing also makes a great difference when your lag time for a single command is measured in terms of minutes and you don't even have that level of "real-time" access most of the time.

    6. Re:And NASA has made mistakes with this before... by kasperd · · Score: 3, Informative

      they have made mistakes in updating from Earth to Mars before.

      Sounds like it was not just a software update gone wrong but rather some mechanical problem which they were trying to work around. It was nothing like the usual bricking problem, where a firmware update overwrites code which is needed to perform future firmware updates.

      The rovers have several mechanisms to make it safer to update firmware remotely. But ultimately a combination of multiple unfortunate events can still lead to the loss of a rover. And one of those events may have been human error. From the description it sounds like mechanical problems with the solar panel, combined with two cases of human error in coordination of updates, another case of human error trying to correct the previous human errors, an unfortunate condition triggering a latent problem introduced by previous errors, and finally ending up in a position causing the battery to overheat, and loss of power being the ultimate reason it was impossible to adjust the previous mistakes.

      --

      Do you care about the security of your wireless mouse?
    7. Re:And NASA has made mistakes with this before... by gagol · · Score: 4, Informative

      That is probably why a team of 100 software engineers issues about 1000 commands per day for the rover. My guess is a lot of the work is triple checking everything before they upload an update. There is just no room for error in this situation.

      --
      Tomorrow is another day...
    8. Re:And NASA has made mistakes with this before... by gagol · · Score: 2

      For those wondering where the numbers come from, just read the article!

      --
      Tomorrow is another day...
    9. Re:And NASA has made mistakes with this before... by K.+S.+Kyosuke · · Score: 5, Funny

      99% of brickings are the result of people doing stuff that the manufacturer did not intend for you to do

      In that case, that should happen with deep space probes quite a lot.

      --
      Ezekiel 23:20
    10. Re:And NASA has made mistakes with this before... by TenDollarMan · · Score: 2

      Yeah, but maybe the new JellyBean will be totally awesome!

    11. Re:And NASA has made mistakes with this before... by Anonymous Coward · · Score: 2, Interesting

      Unbelievable, this is so stupid...
      WHY NOT INCLUDE SECOND BIOS? or whatever fuck they are using? if its so precious and easilly broken, why not use back up hardware? It's not like it would add another half kilo of weight???? Risk is TOO BIG not to do that. A few grams => problem solved.

    12. Re:And NASA has made mistakes with this before... by Sean+Hederman · · Score: 4, Interesting

      First off, shielded hardware is NOT a few grams. A second system adds a significant amount of weight. Each gram added to the rover is several hundred kilos more propellant required. In any case, they DID add a second system, which will take over in the event of an emergency. However, even then, an update is quite perilous, because you could theoretically brick the one system, and if something else goes wrong, you now have no backup.

    13. Re:And NASA has made mistakes with this before... by wmac1 · · Score: 2

      There are 2 separate computers on the board. Perhaps they upgrade one of them and after it worked correctly they transfer control to it and upgrade the other one?

    14. Re:And NASA has made mistakes with this before... by Confusador · · Score: 5, Interesting

      They do indeed have systems like that, if you're interested it's worth looking into how they dealt with the Sol 18 Anomaly on Spirit. Of particular note is the "Shutdown Dammit" command that they used to override everything else the rover was doing so it would stop wasting battery overnight.

      Seeing as they were able to update the software on a device that wouldn't even finish booting, I imagine the procedures for doing it on a functioning device are pretty robust, even if they're still nailbiting.

    15. Re:And NASA has made mistakes with this before... by necro81 · · Score: 2, Informative
      In some cases, the software loaded on the device is not suited to the task the engineers want it to do. TFA mentions that the software on the device now is geared towards interplanetary cruise, EDL, and some very basic on-the-surface tasks. If they actually want the rover to do what they've sent it there to do, they need to perform the upgrade. Why not have the entire suite of mission software on the rover when it launches? Perhaps they hadn't gotten around to coding/testing the on-the-surface software yet. Probably the limiting factor is the program storage space on the rover. According to this JPL website:

      The computer contains special memory to tolerate the extreme radiation environment from space and to safeguard against power-off cycles so the programs and data will remain and will not accidentally erase when the rover shuts down at night. On-board memory includes 256MB of DRAM and 2 GB of Flash Memory both with error detection and correction and 256kB of EEPROM

      Think you'd be able to code everything the rover is ever meant to do, in a single unchanging program image, into just a few hundred kB?

      In other cases, upgraded software provides new capabilities that weren't envisioned during the original design. Spirit and Opportunity, for instance, were given lots of new capabilities over their mission life: like the ability to autonomously navigate based on Simultaneous Locating And Mapping (SLAM) using the various cameras. These are capabilities that were just in development in academia when the rovers were originally programmed, but became proven during the MER mission. As a result of having that autonomous navigation capability, Spirit and Opportunity were able to travel much further distances than they would have if every single wheel revolution needed to be commanded from Earth.

    16. Re:And NASA has made mistakes with this before... by Anonymous Coward · · Score: 2, Funny

      pff worst case scenario : they send him over to mars to jtag the rover by hand...

    17. Re:And NASA has made mistakes with this before... by fisted · · Score: 4, Informative

      It's not a linear relationship since you need additional propellant to move the additional propellant you needed for the extra payload

    18. Re:And NASA has made mistakes with this before... by Frans+Faase · · Score: 3, Informative

      If you would inform yourself, you would know that we are not talking about a general PC with 4Gbytes of memory here, but about a much smaller (but reliable and radiation hardend) PowerPC compatible system with limited RAM. The reason that they planned this update is because they want to remove the flight software for the trip to mars and replace it by software needed to drive and control the rover. It is true that they spend improving the software during the time that the spacecraft was flying to mars. That would be more than logical to do. Please note that the software for the Spirit and Opportunity rover also have been updated several times. It would not surprise me, that when they know the Curiosity Rover better, they will perform another software update.

    19. Re:And NASA has made mistakes with this before... by Bigby · · Score: 4, Insightful

      I think it is safe to assume that they purposely bricked the rover (or test rover) before the mission. And made sure it played out as the GP stated. And that they did this many different ways.

    20. Re:And NASA has made mistakes with this before... by Frans+Faase · · Score: 2

      It is not such a big risk and it has been done many times before with all kinds of space crafts. And you should also realize that many safety precautions has been build into the system. It is definitely not like doing a OS update on a PC. I presume that in case something goes wrong, the rover will get into some kind of safe mode sooner or earlier, allowing to establish communication again. Safe mode communication is at a very slow speed and it could take some time to establish contact again, but in many cases it has been able to revive spacecrafts from safe mode. Please note that the Spirit and Opportunity rover have had several software updates and also experienced multiple events of getting into safe mode for software and hardware errors.

    21. Re:And NASA has made mistakes with this before... by Ruie · · Score: 2

      I think it is safe to assume that they purposely bricked the rover (or test rover) before the mission. And made sure it played out as the GP stated. And that they did this many different ways.

      Ideally - yes. In practice, they have limited funds and lots of deadlines.

      If they had lots of time to debug it, there would be no need to upload new software.

    22. Re:And NASA has made mistakes with this before... by DrXym · · Score: 4, Funny

      Similar to some devices here on Earth, the rover should have an automatic revert solution.

      It does. Scientists put a small switch in at the back which you hold down while powering it up and it will reset itself.

    23. Re:And NASA has made mistakes with this before... by jpmorgan · · Score: 3, Informative

      No, it follows from the Tsiolkovsky rocket equation, and it is linear. The amount of fuel required is exponential in the delta-V required, but linear in the payload mass. m_1 = m_0 e^{- \Delta v / v_e}

    24. Re:And NASA has made mistakes with this before... by uninformedLuddite · · Score: 2

      Why do I always get an erection when I read these sort of comments?

      --
      The new right fascists are bilingual. They speak English and Bullshit.
    25. Re:And NASA has made mistakes with this before... by RockDoctor · · Score: 2

      99% of brickings are the result of people doing stuff that the manufacturer did not intend for you to do

      In that case, that should happen with deep space probes quite a lot.

      ... or it would do, if the manufacturers and the users weren't the same group. Or, for the likes of NASA, the manufacturers of the flight hardware computers and the manufacturers of the flight software weren't two groups of the same organisation, both of whom would take equal accountability for a failure like this. (And probably work in the same building complex, if not the same office block.)

      Which is the norm for deep space devices, wherever they come from.

      Before someone points it out, they do buy in the radiation-hardened processors from an outside supplier. But that is one of the reasons that they are very conservative about which processors they use, to only use processors whose design they understand in great depth.
      In a related recent thread there was discussion about why the imagers on MSL used a 2MPixel sensor. One of the points that didn't get stressed much in that was that all of the imagers on MSL use the same sensor, whether it be a science-imaging sensor, a hazard-hunting imager, or a long-range viewing sensor. They all use the same sensor, because it is a sensor that the JPL imaging team understand well.
      As a different example of the same logic, they chose to not build a zoom lens for the long-range sensor (twice ; they started and stopped the zoom lens programme twice) because they couldn't find a way to build a zoom lens without using "wet" lubrication, and they don't have confidence in the behaviour of wet lubricants under Mars surface conditions, and couldn't afford the weight and power to heat the lens to non-Mars surface conditions. (Which kind-of begs the question of couldn't they put multiple fixed-focal length lenses onto a turret ; but maybe a turret would also have required "wet" lubrication?)

      --
      Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
  2. Actually... only 157 million miles away by ronhip · · Score: 5, Informative

    The spacecraft TRAVELLED 350 million miles to get there, but as of tonight, Mars is only about 157.5 million miles from Earth.

    1. Re:Actually... only 157 million miles away by Anonymous Coward · · Score: 5, Funny

      Forgot something and noticed halfway? Happens to me all the time...

    2. Re:Actually... only 157 million miles away by TubeSteak · · Score: 4, Funny

      Good news everyone!
      NASA will only have to wait half as long to find out if their software upgrade worked!

      --
      [Fuck Beta]
      o0t!
    3. Re:Actually... only 157 million miles away by TenDollarMan · · Score: 3, Funny

      Curiosity made the Mars run in 1.82543347 × 10-5 Parsecs

    4. Re:Actually... only 157 million miles away by RaceProUK · · Score: 2

      Good news everyone! NASA will only have to wait half as long to find out if their software upgrade worked!

      Now read that in Farnsworth-voice...

      --
      No colour or religion ever stopped the bullet from a gun
  3. Not the same cost to get wrong, but by Anonymous Coward · · Score: 2, Interesting

    Working in remote smart metering we have a similar problem, where you can brick meters if the signal drops at the wrong place, or firmware doesn't fit the hardware right.

  4. Wow by undulato · · Score: 5, Insightful

    NASA doing a software upgrade is not big news. This is going to be phenomenally safe. Much scarier doing software upgrades on millions of unknown hardware configurations globally than on one totally locked down platform no matter what distance or cost is involved.

    1. Re:Wow by arth1 · · Score: 4, Interesting

      That reminds me... I have sometimes wondered what security protocols NASA (and their Russian counterparts) have in place for their probes. Back from now to the 1970s, when security wasn't nearly as advanced as it is today.

      Is it possible that someone with a large directional backyard antenna can hack some of the probes? To be remembered as the man who killed Voyager 2 might be attractive for some people.
      And who's to say that this hasn't already happened? There are non-responding probes out there, with no evidence for why they failed.

  5. Hold F8, Boot to Safemode - which lacks networking by DontScotty · · Score: 2

    By pressing F8 at the "Starting Windows 95" message, and then choosing Safe Mode from the Windows 95 start-up menu.

    Following these steps will gain you ultimate FAME and FAILURE - for updating the Mars software!!!

  6. Oblig. by AliasMarlowe · · Score: 4, Funny

    So what's their problem? Just tell a sysadmin to fix it.

    --
    Those who can make you believe absurdities can make you commit atrocities. - Voltaire
  7. Re:Failsafe by Anonymous Coward · · Score: 3, Funny

    Thank you so much Mr. Wowsers for giving NASA this great idea. I suspect, given the genius of the thought, you will be contacted for employment shortly.

  8. Re:Failsafe by zachie · · Score: 2

    This, and also having a full replica of the whole rover on Earth to double check that any software updates won't screw the whole operation. But I can't imagine they are not doing these already :?

  9. Re:hmm by c0lo · · Score: 2

    i hope theres a really, really good reason why the need to update the software at all

    Well, zero-day exploits.. and Wikileaks... and anonymous not forgiving or forgetting... and Duqu/Flame/Mahdi...

    (grin)

    --
    Questions raise, answers kill. Raise questions to stay alive.
  10. Re:Failsafe by fatphil · · Score: 5, Informative

    Exactly. That's how it's done in the telecomms world (infrastructure, not terminals). Typically the new software is given three attempts to boot, and if it doesn't acknowledge that it's fully booted after three attempts, the bootloader falls back to the previous version of the software. Of course, things get tricker if you need to update the bootloader, but those should be very rare situations. However, they in turn can be handled a similar way (typically there's a 3-stage boot, the initial being a ROM bootstrap, then your bootloader, then the OS which you'll want to change).

    --
    Also FatPhil on SoylentNews, id 863
  11. Re:hmm by hey_popey · · Score: 4, Insightful

    Of course, not! They do it just for the lulz!
    More seriously, for space systems and embedded systems in general, due to resource constraints on-board, you usually cannot fit all the functionality you would like to in one software image. So you keep only what is necessary for the first mission, and then you replace the obsolete ones with the next thing you want to do.
    As a simplified example, when you launch a satellite, you will need it to deploy its solar arrays quickly (and do many initialization checks). When that is done, you could imagine changing this part of the software with something else...

    Also, they might have had time planning constraints on the project, and needed to launch with a simpler first version of the software, while finalizing the second one. That does happen.

  12. Re:Failsafe by Anonymous Coward · · Score: 5, Informative

    Computers: The two identical on-board rover computers, called "Rover Compute Element" (RCE), contain radiation hardened memory to tolerate the extreme radiation from space and to safeguard against power-off cycles. Each computer's memory includes 256 kB of EEPROM, 256 MB of DRAM, and 2 GB of flash memory.[22] This compares to 3 MB of EEPROM, 128 MB of DRAM, and 256 MB of flash memory used in the Mars Exploration Rovers.[23]
    The RCE computers use the RAD750 CPU, which is a successor to the RAD6000 CPU used in the Mars Exploration Rovers.[24][25] The RAD750 CPU is capable of up to 400 MIPS, while the RAD6000 CPU is capable of up to 35 MIPS.[26][27] Of the two on-board computers, one is configured as backup, and will take over in the event of problems with the main computer.[22]

    http://en.wikipedia.org/wiki/Curiosity_rover#Specifications

    Data transfer speeds between Curiosity and each orbiter may reach 2 Mbit/s and 256 kbit/s, respectively, but each orbiter is only able to communicate with Curiosity for about eight minutes per day

    When you have little bandwidth, better get it right the first time.

  13. Re:it can fly? by Bonobo_Unknown · · Score: 5, Informative

    The point of the exercise is to replace the no longer needed flight software with software it can use to better perform it's tasks while on Mars.

    --
    We don't believe in radical loony monotheistic religions from the middle east -- we're Christians.
  14. Re:Failsafe by PhunkySchtuff · · Score: 2

    Not only am I absolutely sure they've got more than one copy of critical data in flash, but they have two identical and redundant computers on board
    http://en.wikipedia.org/wiki/Curiosity_rover#Specifications

    From http://marsprogram.jpl.nasa.gov/msl/mission/rover/brains/

    The rover has two "computer brains" one which is normally asleep. In case of problems the other computer brain can be awakened to take over control and continue the mission.

  15. Should have gone with Debian.. by Anonymous Coward · · Score: 2, Funny

    sudo apt-get update mars

  16. Re:Hold F8, Boot to Safemode - which lacks network by wvmarle · · Score: 2

    No keyboard found. Press to continue.

  17. Software upgrades.... by disi · · Score: 2

    It will sit there forever: "Are you sure you want to update? Yes/No"

    1. Re:Software upgrades.... by lxs · · Score: 2

      Have you tried turning it off and on again?

  18. Pressure changes things by jeko · · Score: 5, Interesting

    Get a 10-foot 4X4 piece of lumber. Drop it flat on the ground. Walk from one end to the other like a balance beam. I'll bet you can do it. I'll bet you can do it blindfolded, walking backward. I'll bet you can do it reciting the alphabet backward. I'll bet you could do it drunk.

    Take that same 4X4, suspend it 20 stories in the air between a couple of cranes. Put a bunch of razor sharp, rotating propellers on the ground beneath it. Intersperse the propellers with oil drillbits pointed up, not down for once. Have a bunch of trained turkey vultures flying around to watch you fall. Take your wife, kids and your momma, put a gun in their mouths while the Joker cackles that when you fall, he's gonna blow their heads off. Bring in the television cameras and monitors so the whole World can watch and you can watch them watch. Have some intern read the tweets and comments sections about your plight over the loudspeakers.

    Now, there are a few ice-blooded "Licensed to Kill" Double-O men who could keep it together and walk that beam under that kind of pressure. Mary Lou Retton and Nadia could, no doubt. I seriously doubt I could.

    Is it a big deal to do a software upgrade under such tightly controlled conditions? Not really. But try doing that software upgrade when billions of dollars and your career is on the line, with the whole world watching. The guy who screws that up is gonna be a punchline and a byword for a few decades, a real Wilson if you've read that book. :-) You'll be known as the guy who screwed up Mars.

    Tell me there wouldn't be maybe one or two drops of sweat on the keyboard...

     

    --
    He put his boots up on the table and made a face. "The sig," he smirked. "You can waste your life in search of the sig."
    1. Re:Pressure changes things by fuzzyfuzzyfungus · · Score: 2

      And hell hath no fury like epic nerd-rage...

      If the firmware guys brick this thing, they'll probably be found in either the decompression test chamber with their eyeballs boiling off, or floating in the old hydrazine tank out back.

  19. Re:Failsafe by kasperd · · Score: 2

    What is not clear from the article, is how independent these computers are. E.g. what would happen if the upgrade fails partially, with the main computer trying to take over the craft, while the backup computer is still on the original program.

    That's always a risk if you have two computers for redundancy. To completely solve that problem, you need four computers. But the algorithms for coordinating in such a scenario are complicated. So it might be safer to rely on systems being able to use the proper computer, with just two present. If you had a 3 out of 4 setup with the four computers running identical software, it only takes one software bug to bring down the system.

    --

    Do you care about the security of your wireless mouse?
  20. Re:Failsafe by Jane+Q.+Public · · Score: 2

    "If you had a 3 out of 4 setup with the four computers running identical software, it only takes one software bug to bring down the system."

    Not at all. You have a separate "supervisor" board that moderates among the computers. In a case like that, you only need 3 for Damned Good Redundancy, not 4.

    But I expect that NASA has good reason to have faith in the reliability of their dual machine.

  21. Re:Failsafe by gagol · · Score: 5, Insightful

    Given it is radiation hardened specs, those are fabulous! You cant just get your latest core i7 and expect it to work correctly once it escapes the protection of earth's magnetosphere. Also, heat dissipation is much more trickier when you dont have air to work with (space) or cannot afford top replace air filters for the cooling systems (mars).

    --
    Tomorrow is another day...
  22. There's some good related stories here by Grindalf · · Score: 2, Insightful

    If you follow "Scott Maxwell" in google plus, there are some great snippets about the landing and software. See: https://plus.google.com/u/0/112648317373638762082/posts

    --
    The purpose of existence is to make money.
  23. Re:Failsafe by jkflying · · Score: 4, Informative

    The radiation this thing emits is NOTHING compared to the solar and cosmic radiation it would experience both in transit and on Mars. Putting everything in a metal box only helps so much, you still need specifically designed electronics which can handle the odd bit of radiation without dying. Even with a thick metal box you can't run an i7 on Mars, or not for very long at least. Your standard DDR3 isn't going to work either, or your standard EEPROM.

    The other thing to remember is that although this project is extremely important, they're still not going to throw more capabilities in than they need, because that is more that can go wrong. For a remote sensing platform, the amount of EEPROM isn't that important - you just need enough to hold your communication protocols, some basic reaction-to-obstacle algorithms and the motor control code. You aren't going to be pulling massive libraries in. The emphasis is on making it as simple as possible, so that there is less chance for bugs to creep in. Those extra MIPS will come in handy for the navigation and onboard image processing, and the flash for storing interesting info until you can upload, so those are what they have upgraded the most.

    --
    Help I am stuck in a signature factory!
  24. Should be easy enough by symes · · Score: 2

    They are bound to have a copy of Curiosity here on Earth, surely? So they should be able to thoroughly test the process first. Ok, it is not Mars and there might be issues specific to transmitting that data over such distances... but still. I'd be really surprised if this hasn't been thoroughly tried and tested.

  25. Re:Failsafe by ourlovecanlastforeve · · Score: 2

    They're running vxworks and they do have a backup computer. First the backup is flashed and verified, then the primary is flashed and verified.

  26. Re:Failsafe by kasperd · · Score: 5, Interesting

    You have a separate "supervisor" board that moderates among the computers.

    And then that board becomes a single point of failure.

    In a case like that, you only need 3 for Damned Good Redundancy

    3 computers and a supervisor? That's already 4 components.

    If you want to handle t arbitrary node failures, then you need at least 3t+1 nodes in total. Whether you call the nodes for computers or supervisor boards doesn't change that fact. If you have t failures among 3t or fewer total nodes, then the failures can happen in a way that cause the functional units to receive so inconsistent information, that they are unable to do anything meaningful. It is a case of byzantine agreement.

    Any system designed to handle failures of one third or more components is making assumptions about how the failed components behave. If the failed components behave differently than the assumption, it takes even fewer failures to break the entire system.

    --

    Do you care about the security of your wireless mouse?
  27. Re:Failsafe by fuzzyfuzzyfungus · · Score: 2

    The RAD750 is quite limited in power; but has the advantage of being comparatively close to 'just going down to newegg and buying a motherboard' by the standards of projects that go into space and shop at mil/aero contractors... The price is still up in the "If you have to ask, don't ask" range; but doing a very-low-volume DIY would likely be worse still...

  28. Re:Failsafe by serviscope_minor · · Score: 3, Informative

    Not really. That might have been true 10 years ago.

    No.

    All I'm saying is: you can bet the hardware is in a well-shielded heavy metal box, and today all it takes is about 1/4 of a cubic inch to squeeze in another GB of RAM or flash.

    I wonder why they didn't think about that. A nice thick, heavy metal box. Easy! Perhaps you should go and work for NASA?

    Let's ignore the earth's magnetosphere for the moment and make some massive assumptions.

    The pressure on the ground is about 10^5 Pa. That means there's 10^4 Kg of stuff above you to absorb radiation from space. That equates to 10m of water, 1.25m of steel ot about 90cm of lead. Quite a lot.

    Mars is about 1.5 Au from the sun, so receives about 0.4 times the radiation.cos

    The atmosphere is about 600Pa, by comparison.

    Radiation hardening is a very well established field. Using some degree of shielding is just one of the many techniques in use. On Mars, it is simply not enough on its own.

    It is very, very difficult to make a rad-hard processor, and then very thoroughly test it. Yo can't just keep shrinking the feature size, because is it goes down, the effect of radiation increases. Not only that but as the amount of crystal per transistor shrinks, the chance of unrecoverable lattice damage increases, due to the lack of redundancy.

    There are faster Rad-hardened DSPs, but those are, well, DSPs and only actually really fast for DSP like tasks.

    There also are almost certainly faster ones available now. But it's been in transit for a year, and they certainly weren't building it with a brand-new untested processor for which thay had to write all the software on the way after they launched it.

    So, given the constraints, it's a pretty great CPU to have on board.

    --
    SJW n. One who posts facts.
  29. virus protection by gsgriffin · · Score: 5, Funny

    Probably concerned that their virus software is now out of date after the long journey.

    --
    jsut athnoer menagiensls ltitle psrhae for you to dcoede. Why do we wtsae our tmie dnoig tihs?
  30. Re:Terminology? by the+eric+conspiracy · · Score: 2

    Yeah, the freakin summary is potty as usual.

    They aren't upgrading the flight software. They are replacing the flight software with driving around and exploring software.