Hacker News Reader

Comment by craftyguy | Hacker News Reader

Why couldn't this be re-used to some degree for a rover in non-Earth with tougher, more resilient hardware?

The hardware we use for non-earth stuff is effectively arduino-level (ok, maybe not exactly - but on the order of 70-100Mhz) because of the constraints put upon it by the radiation hardened hardware. Writing python is a trade-off between computer resources and developer time; we've got a lot of developer time and not a lot of hardware resource, so we write in compiled languages.

There are also some safety implications centered around determinism etc which mean interpreted languages are a bit more gray area; with a well understood compiler and language you understand what the code is doing better, and you know it will run the same every time. That may be the case with python if you understand the whole shebang, but not that many people do... And if you have that level of knowledge of python, you may as well be writing C or C++.

Do you find C/C++ acceptable from a safety/reliability perspective, or do you write in safer languages (Fortran, Ada)?

AFAIK critical software coding standards forbid dynamic memory allocation, so things like stack overflows, null dereference or out-of-memory errors can't happen, but array-out-of-bounds exceptions can still get you. On the other hand, static verification tools catch most of that.

C/C++ is fine as long as you adhere to coding standards like MISRA and you thoroughly test it. Our code for example, is unit tested, then we have java tests running on a server-based simulator, then other independently written java tests running on test benches that more closely represent the spacecraft itself, then a replica of the spacecraft.

The industry used to use Fortran / Ada quite extensively, and depending on company/organisation and team, might still do so. Things like the F-35 are written in C++, which is where I can see these things heading.

Safety critical standards indeed forbid memory allocation usually. If you want more details you can search for MISRA C (automotive market), the standards can be found online.

That being said, stack overflows and null derefs are not caused by dynamic memory allocation, so you still have to be careful about those and use some other rules / tools to protect you.

has JPL ever investigsted alternative real-time systems? say a real-time ML (as in sml, f#, etc.)?

Rover management was against anything modern or dynamic. They only trusted proven technology. Even if it was hardened C.

Because it’s made out of consumer bits and pieces that talk on serial bus with little or no environmental protection (with electronics and sensors distributed in a way that’s probably not practical to do so to the level required).

For non-earth you’d probably just want to start again.

Reply on news.ycombinator.com