<div dir="ltr">Of course.<div><br></div><div>Sadly the article is very light in technical terms (I suppose the main audience is non-technical people), so I can't really tell if they're doing the whole shebang with separate hardware and software stacks. It incurs in extra cost and complexity per launch (you may not get the same bug on both systems but you're probably sure as hell to have different bugs), and maybe the benefits aren't that great compared to having one exhaustively tested, understood, software and hardware stack so the cost-benefit relation is just not worth it - especially since one of SpaceX's stated goals is to provide "cheap" access to space.</div>
<div><br></div></div><div class="gmail_extra"><br clear="all"><div>--<br>João Neves</div>
<br><br><div class="gmail_quote">2014-02-17 13:44 GMT+01:00 Miles Fidelman <span dir="ltr"><<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Interesting.<br>
<br>
What I find particularly notable about the Space Shuttle design is the notion of separate development of hardware and software - by different teams at different vendors - as a fault checking mechanism.<br>
<br>
I guess the core mathematics has to be the same (e.g., ballistic calculations), but beyond that, different code, running on different hardware, but they have to get to the same results, or something is wrong.<br>
<br>
More copies of the same hardware/software just means more copies of any bugs!<br>
<br>
Cheers,<br>
<br>
Miles<br>
<br>
<br>
João Neves wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
SpaceX also does it and is a central part of their design:<br>
<br>
"Q: So, these flight computers on Dragon – there are three on board, and that's for redundancy?<br>
<br>
A: There are actually six computers. They operate in pairs, so there are three computer units, each of which have two computers checking on each other. The reason we have three is when operating in proximity of ISS, we have to always have two computer strings voting on something on critical actions. We have three so we can tolerate a failure and still have two voting on each other. And that has nothing to do with radiation, that has to do with ensuring that we're safe when we're flying our vehicle in the proximity of the space station.<br>
<br>
I went into the lab earlier today, and we have 18 different processing units with computers in them. We have three main computers, but 18 units that have a computer of some kind, and all of them are triple computers – everything is three processors. So we have like 54 processors on the spacecraft. It's a highly distributed design and very fault-tolerant and very robust."<br>
<br>
(<a href="http://www.aviationweek.com/Blogs.aspx?plckBlogId=Blog:04ce340e-4b63-4d23-9695-d49ab661f385&plckPostId=Blog:04ce340e-4b63-4d23-9695-d49ab661f385Post:a8b87703-93f9-4cdf-885f-9429605e14df" target="_blank">http://www.aviationweek.com/<u></u>Blogs.aspx?plckBlogId=Blog:<u></u>04ce340e-4b63-4d23-9695-<u></u>d49ab661f385&plckPostId=Blog:<u></u>04ce340e-4b63-4d23-9695-<u></u>d49ab661f385Post:a8b87703-<u></u>93f9-4cdf-885f-9429605e14df</a>)<br>
<br>
<br>
--<br>
João Neves<br>
<br>
<br></div>
2014-02-17 13:29 GMT+01:00 Miles Fidelman <<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a> <mailto:<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@<u></u>meetinghouse.net</a>>>:<div class="">
<br>
<br>
Jesper Louis Andersen wrote:<br>
<br>
<br>
On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman<br>
<<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a><br>
<mailto:<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@<u></u>meetinghouse.net</a>><br></div>
<mailto:<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@<u></u>meetinghouse.net</a><div><div class="h5"><br>
<mailto:<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@<u></u>meetinghouse.net</a>>>> wrote:<br>
<br>
Good point. "Let it crash" does take on a whole different<br>
meaning<br>
when dealing with aircraft and such.<br>
<br>
<br>
This is a different point as well! You have two axis:<br>
<br>
* soft vs hard realtime. Some systems require hard realtime<br>
and then your tools are limited to languages where you have<br>
explicit memory control, enabling you to avoid allocating<br>
memory and triggering garbage collection. In soft realtime<br>
systems, you have more leeway, and if built the way of the<br>
Erlang runtime system, you get really good soft realtime<br>
capability.<br>
<br>
* Proactive vs Reactive error handling. The idea of "let it<br>
crash" is definitively reactive, whereas static type systems,<br>
proofs, model checking, etc are means of proactive error handling.<br>
<br>
My claim however, is that you need "Let it crash" in Aircrafts<br>
as well if you want to have a stable aircraft. The model where<br>
you blindly attempt to eradicate every error from a program is<br>
bound to fail sooner or later. Usually "let it crash" in those<br>
situations is implemented in hardware by having multiple<br>
redundant systems. But rarely are systems exempt of failure.<br>
Even in a highly controlled environment.<br>
<br>
<br>
We've really strayed off-topic here, but....<br>
<br>
My all-time favorite design for seriously mission-critical systems<br>
was the flight control system for the Space Shuttle. I'm not sure<br>
this is true of the later versions, but originally:<br>
- the flight control software ran on 5 parallel computers, that<br>
voted on results<br>
- 4 of the computers came from one contractor (hardware and software)<br>
- the 5th machine, just ran mission-critical code, with a<br>
completely separate design (both hardware and software)<br>
- I don't remember how the tie-breaking algorithm worked<br>
<br>
Cheers,<br>
<br>
Miles<br>
<br>
<br>
<br>
<br>
-- In theory, there is no difference between theory and practice.<br>
In practice, there is. .... Yogi Berra<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br></div></div>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
-- <br>
In theory, there is no difference between theory and practice.<br>
In practice, there is. .... Yogi Berra<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>