ESA: Sorry about Schiaparelli, can we have another €400 mill? Later this week in Lucerne, Switzerland, the European Space Agency (ESA) will ask its 23 member states' ministers for a €400 million top-up to its ExoMars program. In an audio conference on Friday, director of human spaceflight and robotic exploration David Parker said the cash injection “includes all the technical work needed …
No one says N-A-S-A. On the other hand as far as I know ESA is always pronounced E-S-A. That's enough to justify using/not using the definite article. Of course, that probably means that we should write 'Nasa' but i imagine the agency - like my spellchecker - objects. (They can't do much about the pronunciation, though).
Never heard anyone say "E.S.A.", definitely not people working in ESA.
The Register hopes at least some goes into software testing.
If the choosing nine correct testing scenarios depended on the live of a Schroedinger's Cat that absolute tries to survive, one could expect success.
That would explain it - as others have said above, I only ever hear of the agency being referred to as "EEE-SAH" so it sounds a little odd when I read the articles to hear (in my head) "the EEE-SAH" just as it would be odd to hear "the NAH-SAH", but if the author is hearing "the EEE-ESS-AY" when they write it that makes more sense.
Most abbreviations tend to get the definite article: theCIA, etc; MI5 being an exception. So I tend say the NASA and the ESA. Whether acronym gets contracted into a noun is another matter and one of preference, though with only three letters it doesn't make much difference. Longer than that, eg. NASA, and the lazy brain will tend to try and speak it.
>Well, OK. But you've got to promise to test the damn software this time.
Pete 2, I see you are keen to help out with the software testing, right ? I thought so, please send your CV with references. I hope you know Newtonian laws by heart as well as Einstein's relativity theories and how they impact small objects landing on distant planets. You also need to remain calm and be predictive because of the delay between commands you issue to the vessel and the reaction of the vessel.... can be quite big delays. It's like playing Crisis on an i386 with software rendering, so the software needs to be really precise!
I haven't had a chance to follow the details of this one but I don't thing a lack of software testing is the only thing to blame. And since Ariane 5 the ESA has a heap of people pouring over the code.
I'm a huge fan of software testing. But, as Gary Bernhardt says, you're often restricted to testing "known unknowns". Sending probes to foreign planets tends involve heaps of "unknown unknowns". This is rocket science after all!
Rosetta went quite well with software that was developed years ago. Simplicity is the key.
Software testing is not enough. One needs to have formal verification of teh softwrae but aso of teh system design. What were the assumptions? As far as I can read, a sensor gave an overflow. From ESA's website: "However, saturation – maximum measurement – of the Inertial Measurement Unit (IMU) had occurred shortly after the parachute deployment. The IMU measures the rotation rates of the vehicle. Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.
When merged into the navigation system, the erroneous information generated an estimated altitude that was negative – that is, below ground level."
This begs the questions: did the software take into account larger then expected values? This is often overlooked and the remedy is simple: clamp the data. If the sensor was in error, was there a back-up sensor? Were feasibility checks included? Etc. It is not so likely that testing alone will find this because testing cannot always simulate unspecified states. The process needs to included several reviews and confirmation activities. This type of errors (if confirmed) look a bit like beginner's errors. An academic environment could be the cause. It's only when engineers hit a few times the wall, that hard lessons are learned.
to give a kick along to smaller and startup space companies developing “software, hardware, and integrated solutions for companies using satellite data”
The ESA has a long history of working with university spin-offs to get stuff done: it's how Surrey Satellites got started.
When it comes to things like Exo-Mars then comparisons with Space X and Blue Origin are completely specious. None of this stuff has been done before, ergo, none of it has been commodified and can be done cheaply.
As any fule kno, the biggest cost of any mission is getting whichever contraptions you have from the earth to the destination (out of the earth's gravity well and into Mars' orbit). My scribbles on the back of an envelope that, given the current cost of routine satellite launches, $ 500 million isn't expensive for going to Mars and still better than trashing the main lander "to see if you've fixed the problem".
On projects like this you need teams that will work hard to find out what went wrong, who will own up about it publicly, and management that will back them. So kudos to the ESA for doing this.
I used to be a little annoyed at the truly oddball issues found by my former company's software testing team. I wondered "why on earth would they even think to do that..."
Then I've also noticed my young son's strange way of playing video games...jumping all the time, trying to walk through walls, etc. As if he's trying to break the software.
Reading this article it dawned on me that maybe this is precisely the kind of thing we could use more of in software testing. In additional to testing the usual and expected behaviors, and as many "not expected but still possible cases" as you can dream up, also doing some *truly odd things* to the software from time to time may prove really useful!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
