Slashdot Mirror
Software Error Caused Soyuz/Galileo Failure
schwit1 writes An investigation into the recent failed Soyuz launch of the EU's Galileo satellites has found that the Russian Fregat upper stage fired correctly, but its software was programmed for the wrong orbit. From the article: "The failure of the European Union’s Galileo satellites to reach their intended orbital position was likely caused by software errors in the Fregat-MT rocket’s upper-stage, Russian newspaper Izvestia reported Thursday. 'The nonstandard operation of the integrated management system was likely caused by an error in the embedded software. As a result, the upper stage received an incorrect flight assignment, and, operating in full accordance with the embedded software, it has delivered the units to the wrong destination,' an unnamed source from Russian space Agency Roscosmos was quoted as saying by the newspaper."
A software error in Russian GLONASS receivers has resulted in thousands of Russian troops innocently crossing the border into Ukraine.
"National Security is the chief cause of national insecurity." - Celine's First Law
It's not like it's rocket science to get it right
Table-ized A.I.
the strategic value of satellite navigation and general asshole-erly at the top of the Russian government, I am guessing that Europe's very expensive satellites ended up exactly where Russia wants them.
This is not a SW error! The software put them right where they were told to. The orbital parameters were wrong! This is a data error not a SW error!
There's almost no overlap between the skills & techniques necessary to write & verify critical software (e.g. when lives or huge amounts of money are on the line) vs. what is considered to be "programming". Modern software engineering's approach to reliable system design is about where hardware engineering was fifty years ago, and about where civil engineering was 100 years ago.
SQA is a joke. Reliable systems are made using way more robust techniques, including: (a) a severely restricted state space, (b) redundancy, (c) formal proofs, (d) fully (and formally) specified interfaces, (e) random simulation, (f) several different types of coverage, (g) physics-based analysis, etc.
The failure of the software community to understand this distinction is why I'm scared to death about the coming world of driver-less cars and robots performing surgery. How many people are going to be killed by C++ in the next decade?
it's just a matter of time until the unwashed hordes of C++ monkeys are unleashed unto critical systems.
No way. The corporate lawyers will never let that happen. Neither will the regulators. It is very hard to certify a SDC for public roads. Reams of test data are required. It is even more difficult to get a medical device approved by the FDA. Therac-25 happened almost 30 years ago, a lot of lessons were learned, and it hasn't happened again.
Bridges aren't designed and tested by "trial & error" ... Neither are buildings or pacemakers or computer chips.
I have never designed a bridge or pacemaker, but I have designed computer chips. I sit at a workstation, and I type Verilog code into Emacs. It is the same process as writing software, which is mostly trial and error. I write unit tests, do regression testing, etc. I watch it fail, I fix the bugs, and I iterate. Once I get all the bugs fixed, I load it into an FPGA, and watch it fail with some signal skew that I didn't think of. So I write more tests, and repeat. When it runs flawlessly on the FPGA, I ask a co-worker to test it some more, and review my code. Eventually we go to silicon, where a bug costs a million bucks. Usually everything is fine, but that isn't because it is "different" than doing software. It is basically the same process. It is more reliable because most ICs are far less complicated than even a typical iPhone app. They tend to have lots of the same cells repeat over and over. So an IC with a million gates isn't like a million lines of code. It is more like a few dozen 50 line subroutines, that are called a million times.