Software error doomed Japanese Hitomi spacecraft(scientificamerican.com) |
Software error doomed Japanese Hitomi spacecraft(scientificamerican.com) |
The spacecraft then automatically switched into a safe
mode and, at about 4:10 a.m., fired thrusters to try to
stop the rotation. But because the wrong command had
been uploaded, the firing caused the spacecraft to
accelerate further. (The improper command had been
uploaded to the satellite weeks earlier without proper
testing; JAXA says that it is investigating what
happened.)
Going into safe mode is a thing. It happens with NASA stuff, ESA stuff, whatever. The spacecraft failed to stabilize and went into safe mode, and that's proper. Whatever glitch in the systems, this would have saved it and allowed for recovery.But the uploaded command to shed rotational velocity was wrong. This is what caused the loss of the spacecraft. I'm sure there will be a pretty heavy postmortem on how this happened.
All the available testing programs in the world doesn't matter if the tests aren't run.
As far as I understand it, Satellite design is all about cramming the most amount of features in as small and light a package as possible. That would mean a lot of tight coupling and a hard time standardizing anything across different types of satellites.
Is this another sign of how bad japanese hardware-oriented companies and organizations are at doing software? Like the organisational software crisis at Toyota?
Or was it a fluke?
Two things to keep in mind:
* Don't compare JAXA (or anyone else) to NASA at this point. We (the US) have a ton of experience, some of it bought the hard way.
* This isn't Japan's typical performance. They have a nice string of very good space science missions. And don't forget things like the Mars Climate Orbiter[1], where ground based commands sent it through the atmosphere due to a unit mix up.
I suspect it has to do with the scale of integrators in the country being much smaller, and lacking in terms of B2B collaboration.
There are some jewels here and there, though. It's probably just a matter of culture. Maybe they're also somewhat isolated from the English and Chinese language leads in software development. I don't think Japanese English language education is very effective. Their popular courses likely don't leave an individual comfortable with technical reading in English.
Lots of these subsystems can be tested in a pure software simulator. Esp when it comes to faults.
Why?
Space is hard, and in many cases you have only one chance to get it right.
On November 14th 1971 NASA's Mariner 9 became the first spacecraft to successfully orbit another planet.
...
Except what came back ... were not pictures of the intricate canyons, craters, and mountains of Mars, but pictures of a blanketed world, a dust enshrouded mystery. Mariner 9 had arrived in the midst of one of the greatest global storms humans have ever witnessed on Mars.
[1] http://blogs.scientificamerican.com/life-unbounded/the-great...
That's probably true. But I think your statement is unnecessarily focused on Japan. The following is also true:
large hardware companies tend to be really bad at software
Is there not a Japanese version of Stack Overflow? Maybe there should be?
A Japanese Stack Overflow would inevitably be less useful than access to the English Stack Overflow.
The analysis of Toyoda's software that might have been behind the claimed acceleration/can't stop the engine problems indicates that even there, at least Toyota is all but hopeless.
> There are a large number of functions that are overly complex. By the standard industry metrics some of them are untestable, meaning that it is so complicated a recipe that there is no way to develop a reliable test suite or test methodology to test all the possible things that can happen in it. Some of them are even so complex that they are what is called unmaintainable, which means that if you go in to fix a bug or to make a change, you're likely to create a new bug in the process. Just because your car has the latest version of the firmware -- that is what we call embedded software -- doesn't mean it is safer necessarily than the older one….And that conclusion is that the failsafes are inadequate. The failsafes that they have contain defects or gaps. But on the whole, the safety architecture is a house of cards. It is possible for a large percentage of the failsafes to be disabled at the same time that the throttle control is lost.
> Even a Toyota programmer described the engine control application as “spaghetti-like” in an October 2007 document Barr read into his testimony.
http://www.safetyresearch.net/blog/articles/toyota-unintende...
The priority seems to be reliable real-time computation, and the solution is to calculate everything as a continuous function. Anything that would be a branch is instead a binary mix of the conditions, triggered with a threshold function.
I can think of many ways of structuring programs which are spaghettiish in C, but would yield the desired results in an automotive ECM.
But yeah, I agree, whenever a large Japanese company that is not Nintendo does software (at least for consumers), you can pretty much expect a disaster.
(I know there's a small group of startups that do good stuff - I am not talking about them.)
Obviously I'm biased, but I agree Nintendo is the only major Japanese company that has any idea how to write software. They also have a legacy of incredibly talented programmers that they respect more than most Japanese companies.
After Russia, US, and China, Japan has the most satellites in orbit.
China which is always called on its quality control went 16 for 16 launches, and they launch other countries satellites too. They also landed on the moon in 2013. Ironically, they still can't make a ballpoint pen as good as the Japanese,Swiss or German ones due to consumer spending habits [1].
Somebody mentioned South Korea as a comparison. Well they only have 16 compared to Japan's 153 satellites. Japan's space program is scientific, while there are military launches in the US, Russia and China with those budgets hidden to develop such capability.
Japanese robotics are amazingly performant,so they must be doing something right there both hardware and software-wise. Realtime sensor data coupled with mechanics, mechatronics. Funny, anime has robots with rockets, and yet Japan produces the world's top humanoid robots vs. the military and seemingly menacing robots from Boston Dynamics (Alphabet, Google). Although, Atlas is giving Asimo a run for its money.
A lot of satellites were launched off of Soyuz (Russian) rockets too. The UK launched one satellite on its own rocket in 1971, and now piggybacks or rents time on satellites.
Space launches are expensive, technically challenging, and still risky. SpaceX lost the 8 cubesats on the June 28th launch failure. Mechanical, not software, but it shows the risks involved are not isolated to a single country over another, software or hardware.
[1] http://www.marketplace.org/2015/12/10/world/why-cant-china-make-good-ballpoint-pen void doit(const tststructptr* in) {
assert(in); /* Because we test our code, for safety */
const tststructptr t = *in;
if ( t.t1 && t.t2 && t.t3) { f1(); }
else if ( t.t1 && !t.t2 && t.t3) { f2(); }
else if ( t.t1 && t.t2 && !t.t3) { f3(); }
else /* TODO: Fix, this should never happen */
releasenerveagent(SLEEPINGQUARTERS);
}
A long sequence of ternary operators allow for a prettier layout, but is more error prone.I mean, which other large american hardware-centric companies have managed the transition to software well?
I haven't used a PlayStation in a long time so I don't know the current state, and I would guess Nest is not helping the US side of the equation. Apple isn't exactly covering itself in glory in the last couple of iOS releases (never mind the "California" series of OS X releases).
The PS4 has a weird UI that feels oddly half-finished, but does okay on system level performance. It's sort of where the Xbox 360 was in 2005.