Expert Was Needed to Disable Malaysia Airlines Jet Systems
online.wsj.com
online.wsj.com
It's a triple redundant system, that is there's 3 separate PFC systems. That's not too surprising.
What did surprise me was that each of the 3 PFCs has 3 channels, and each channel is a CPU from a different manufacturer (AMD, Motorola, Intel). The reasoning is that any flaw in any particular cpu design would be outvoted by the other two.
They appear to use 3 different compilers for this reason (Ada), one for each processor. Seems like the I/O and endianness of the various chips would add complexity too.
I wonder if the added complexity makes it a net win or loss for safety? I guess a win, since that's what they do.
I understand why Ada is used for safety-critical applications, but I have to wonder: Does the fact that Ada is a relatively old and unfriendly language lead to more bugs than it prevents? My mind would probably go blank if I had to stare at Ada code for 8 hours a day.
What if we used Haskell for all non-realtime safety-critical functionality in aircraft? With a few extra rules to prevent stack overflows, I think I'd trust a million-line Haskell program over a million-line Ada program (although it would probably be more like ten-thousand-line Haskell program vs million-line Ada program).
I would most certainly not trust Haskell over Ada in embedded system work.
So does coding in assembly. The idea is to create fast, efficient code that is also simple and easy to understand.
>I would most certainly not trust Haskell over Ada in embedded system work.
If the system does not have hard realtime requirements and has a decent resources, why wouldn't you trust Haskell?
Because that doesn't describe cars, a jet, space shuttles, or ... well anything I'd trust my life to. Hell, Haas CNCs still run DOS 8.0
(IIRC, these programs don't even use malloc, let alone garbage collection :)
In fact, I'd say a great way to do it would be to implement all the hard realtime bits in some low-level, pain-in-the-ass language like Ada and then wrap all that unpleasant stuff in a high-level language that is very unfriendly to implementation bugs (like Haskell).
I'm not convinced you can make such a clean separation.
Don't think you know what a hard real time system is. Both radio transponders and life support systems have to be hard real time. Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code. The "human interface systems" (could you have brought to the conversation a more generic term?) to all of these are often, too, hard real time because that's the easiest way to prove something is safe and test the edge cases. For all intents and purposes, anything "soft real time" has a kernel and kernels are monolithic disasters waiting to happen for anyone who needs timing guarantees (hint: if your life depends on it, it needs timing guarantees).
On top of that is the unfriendliness of Haskell to the real world of hiring (and this is Boeing for godzilla's sake) and it's lack of proper testing in such an environment, although I'm sure there are those who use it in embedded.
Motors and antennas are usually managed by hardware or dedicated uCs, not PFC software. Aircraft aren't running their telemetry off GnuRadio, and aircraft PFCs sure as hell aren't worrying about servo timing.
"Human interface systems" I thought would be self explanatory; pilots don't care if their plane UIs take 5us or 5ms to update. They can't react on those time scales anyway. Hell, you could probably code all the user-facing avionics stuff in Javascript and be fine.
Hard real-time doesn't mean "fast", it means having guaranteed upper bounds on response time. In order to get those guarantees, uninteruptable code paths need to be short and critical parts of the systems need to be simple, which often also leads to fast response. However, the difference between soft and hard realtime systems is the guarantees.
A soft real-time system that has a 5ms mean update time but has a 1e-6 chance of taking 10 seconds is much less useful than a hard real-time system that has a 15ms mean update time with a hard upper-bound of 50ms.
But based on my meager experience in the language, I disagree that Ada is a massive pain in the ass to program in. It's probably less verbose and friendlier than Java, for example. Certainly easier than programming in C, and much less prone to fatal mistakes.
Please don't give anyone any stupid ideas.
I learned with "ADA as a Second Language", but its way out of date and I do believe out of print.
Also as others have commented there are usually special requirements for embedded systems that may even occasionally require one to drop down to assembly (e.g. to get the code in the right place to execute if you're on bare metal).
It won't help with with static analysis of any numeric types (though you can turn bad conversions into type errors, it can't tell if an explicit conversion is right or not) and the timing of anything is really hard to reason out.
The type system.
When I write Haskell programs, I create orders of magnitude fewer bugs than I do when writing programs in other PLs.
The language makes it very hard to screw up implementing an idea.
Haskell forces me to implement things in ways that are both elegant and easy to comprehend. Haskell does not easily admit spaghetti code.
-> http://www.open-do.org/projects/hi-lite/gnatprove/
http://www.open-do.org/wp-content/uploads/2011/12/hi-lite-er...
The closest you're going to get it something like Atom [0] which is used to program a few different hard realtime systems. If you look at the Atom docs, however, you'll quickly find that programming in Atom is nothing like programming in Haskell---it's merely embedded there. The type system helps to ensure that your embedding does falter, but most of the errors still live in the sublanguage and I'm not sure how far Haskell's type system goes toward reducing those.
It means that there's an increased chance of bugs overall, yes, but a decreased chance of bugs that affect the overall flight, as it means that many more bugs will be caught and dealt with before they start affecting things majorly.
It doesn't save you from flaws in the design specs, though, or if everyone made the same faulty assumption.
As I've found myself: the best way to test an implementation of a data structure is to compare it against another implementation (preferably the simplest implementation possible - singly linked list, anyone?) and assert that they exhibit identical behavior.
> Q. How are actuators controlled?
> A. For the aerosurface actuators, each of the four computers sends out an independent command on an independent bus. With no failures, the commands should be identical. The voting is done at the actuator using a hydraulic voting mechanism, called a force-fight voter. In it, there are four hydraulic ports called secondary ports, each commanded by one of the four GPCs. The secondary ports go into the primary ports, which are heavy-duty actuators that connect to what's called a "summing bar," which is no more than a massive steel rod. If there are three good computers and one bad one, the three good commands physically out-muscle the fourth. This limits the control authority a little bit--we don't get the total force we'd like to get, but there's still enough power to control the vehicle. If you have a large enough pressure differential for a large enough time, the port is hydraulically bypassed, which relieves the pressure in that one port. The remaining three ports then regain their full authority.
The whole article is worth a read: http://klabs.org/DEI/Processor/shuttle/shuttle_primary_compu...
Homer: Well, today's the day for Homer J. I know I'm
gonna win this time.
Lenny: Yeah? How come?
Homer: Union Rule 26: "Every employee must win Worker of
the Week at least once regardless of gross
incompetence, obesity or rank odor."
Mr. Burns: Compadres, it is imperative that we crush the
freedom fighters before the start of the rainy
season. And remember, a shiny new donkey for
whoever brings me the head of Colonel
Montoya... Hmm? What? Oh! ...and by that I
mean, of course, it's time for the Worker of
the Week Award. I can't believe we've
overlooked this week's winner for so very,
very long. We simply could not function
without his tireless efforts. So, a round of
applause for this inanimate [steel] rod.1. used a different CPU architecture and brand 2. used different circuits 3. used different algorithms 4. used different languages 5. were developed by independent teams 6. with a third independent team to verify there were no inadvertent similarities
If the two channels disagreed, they were automatically electrically isolated, and the pilot was notified and was expected to take over.
For this reason it was rejected for use on the 777 by the FAA Chief Scientific and Technical Advisor for Flight Controls.
With regard to the 777 Flight Control System Design, "Bob Yeh" released a number of documents on the system.
http://www.citemaster.net/get/1472830e-8785-11e3-9b63-00163e...
http://www.reuters.com/article/2014/03/09/us-malaysia-airlin...
The chance of one or more of the systems failing actually triples (OR), but the chance of all three failing (AND) decreases, which is what redundancy provides. Basic probability.
[1] http://www.airliners.net/aviation-forums/general_aviation/re... - Currently the most recent thread.
"It doesn't make any sense somebody could hijack a plane that easily - you know, just deactivate the transponder and be gone - it's not that simple, of course - that would be ridiculous - and there is radar everywhere. Also the earth is covered with photo satellites - they would find the plane in no time - you know, a plane is a pretty big thing - haha - so anyway, bit naive, but the acting was alright - so if it wasn't about the transponder plot hole I'd give it a solid 8 ..."
When handing over from one ATC to another, MH370 adopted the identity of another plane in the area, and the other plane switched off it's transponders (let's call this other plane AB123). Leading to a scenario where the whole world is looking for a plane in the sea when it's actually airborne, but just happens to look like another plane on radar, and they landed it at some backwater airport (AB123's destination) that's under terrorist control (for example, how big a team would you need to take over Port Blair Airport on the Andaman islands? I'm guessing not very many, and no would be any wiser if you ran it as normal)
But why do this? Because whoever stole this plane needs to be able to fly MH370 into someones airspace unnoticed to do something bad, and flight AB123 is scheduled to fly into that airspace sometime soon, but if flight AB123 had been hijacked, or had gone missing, it would raise alarms. But to the outside world, flight ABC123 is fine, it's MH370 that everyone is worried about... but flight AB123 is MH370.
So where is AB123? I don't know. Maybe thats the plane the oil rig worker saw crash, or maybe they figured out some other way to hide it. Perhaps both planes flew to AB123's destination, but with one flying directly above the other so that it looks like one plane on radar (I don't know how Radar works but this would work for a movie) Also, AB123 might not be a passenger jet, it could be a cargo plane, or some other kind of plane that doesn't come with a bunch of passengers that people would miss.
Anyhoot, that's my crazy theory and even I don't believe it, but a small part of me hope's it's right because the people on Flight MH370 could still be alive.
At the very least, I think this is a good plot for a movie.
You postulate two planes in the same area, that would look roughly the same on primary radar when their transponder was off (or maybe I misread you/assumed incorrectly about both looking big, see below). "Biggish" in that the 777 is a rather large aircraft with a presumably large radar cross section, "pip" as in a blob of light appearing on the radar's screen.
Going further, when they looked at the recordings of what their radar(s) saw, they'd see one "biggish pip" suddenly returning transponder information and another stop ... it's hard to imagine coordination to the split second, although it's possible.
Ah, I see one way in which I could be wrong: assuming the use of a small jet, it could be configured with a powerful enough transponder to simulate the 777's. So both pips would not necessarily be big, and if the location was carefully chosen maybe the small jet's wouldn't be seen by the radars. And that's more likely, after all, if they had a big jet to start with....
But back to being serious for a second. If mh370 really did keep on flying for five hours on the route that has been suggested, is there any other way it could go unnoticed? I'd like to think that it's impossible for something the size of a 777 to fly unhindered through the sky over several countries post 9/11. But then again, I had hoped someone couldn't make a plane vanish seemingly at the flick of a switch.
You seem to know your onions, is it possible to have two planes flying close enough together that they show up as one blip on radar? What's the pixel to kilometre ratio on those things?
I don't know specifics of radar, just the general principles. The major possibility here is that your suggested transfer of which transponder is saying "I'm MH123 at the same altitude" happened at a range where no radar would be giving a good enough return from the putative small jet assuming the role. Which upon review wasn't the scenario you were positing.
And if it was giving enough of a return to be seen, especially in retrospect as experts reviewed it, well, we'd have heard about it by now.
But if AB123 was big, we'd really have heard about it and it's near collision with MH370, or someone would be wondering why AB123 moved really quickly a noticeable distance at the same time MH370 went off the air. Or perhaps AB123's altitude was different, they were far enough the radars' couldn't tell that, and it's transponder was customized to lie about the altitude.... But people would still wonder, and would be questioning AB123's flight crew if they saw anything, etc. etc.
(I'm tired enough the above isn't entirely coherent, but it'll give you some things to chew on.)
Once mh370 goes missing, it stays missing. The trick is in making it look like ab123 is behaving normally. And while everyone is distracted by the search for mh370, I wonder how closely they would be looking at irregularities in other flights that aren't missing and aren't reporting any problems.
http://keithledgerwood.tumblr.com/post/79838944823/did-malay...
http://www.cbsnews.com/news/malaysia-airlines-flight-370-mor...
Who else is saying this and where?
------------------------
Disclaimer: I know nothing about planes.
That being said, this seems like fodder for conspiracy theories and click throughs. Under normal circumstances, yeah, I bet it's hard to disable. However, if we assume the plane crashed, we know there was a massive malfunction -- seems more likely to me that it was a part of that.
However, the fact that India and the US is deploying so many assets on the other side makes me suspect they might have some credible leads. I am guessing India is possibly working more with the US than anyone else; given that India wouldn't want China to know what capabilities they have there.
On the disappearance of MH730 it seems a lot of people are happy to make the unfathomably large assumption that this was "probably" a catastrophic mechanical failure and that the plane has crashed into the sea, despite the conspicuous absence of any evidence for this scenario such as mayday calls, or a wreckage and now, in the face of overwhelming evidence that directly contradicts the theory that the plane has crashed (because it appears to have been under the control of a skilled pilot for five hours after it went missing, and skilled pilots are usually pretty good at landing planes) people are still positing the notion that the plane has crashed and that Occam's Razor somehow supports this point of view.
In short, "the most likely explanation" in this case, is the one that makes a boat load of wild assumptions.
Um, yes. Multiple radar base stations and immarsat pings.
http://www.avherald.com/h?article=44078aa7&opt=0
Answers are in the past.
It seems like aircraft fires occur more often than hijackings. Is there any reason at this point to prefer the hijacking theory, other than that it's a bit more sensational?
TrevorJ is a lot closer to the mark, although it wasn't the engine system phoning home, it was some sort of generic hourly "ping" with no other content (since the airline didn't sign up for the service that would have done more). Since these were pings from or to IMARSAT geosync satellites, very rough estimates of where the plane could be have been were made from them. I assume based on which satellites heard them (vs. ones over the horizon), perhaps comparing time-stamps and transit times to 22,000 miles in orbit, etc.
But of course the bottom line is that these pings went on for hours, which evidently would only stop when the engines stopped for whatever reason. That makes a plausible fire scenario more complicated.
Malfunction in plane - transponder turns off - cabin loses pressure (and everyone on plane goes unconscious or similar) - because cockpit is locked crew does not manage to do anything in time - plane keeps on going - fuel runs out.
of course that is probably totally wrong.
One thing though - if it did fly low over land - I would expect at least someone would have used their cell phone - so I would rule out that option.
The "corridors" are actually geometrically symmetrical arcs as you suspect, somewhere around which it's believed the plane traveled until the pings stopped, presumably because the engines stopped running.
[1] https://en.wikipedia.org/wiki/Malaysia_Airlines_Flight_370
[2] http://edition.cnn.com/2014/03/14/world/asia/malaysia-airlin...
Don't know which satellite series is used for this service, but the Inmarsat constellations aren't particularly large: http://en.wikipedia.org/wiki/Inmarsat#Satellites, so it could be they only got solid data---and it's not very specific---from one satellite.
I also wouldn't put much confidence in mass media reports saying "satellites", and the Wikipedia plural use is probably based on them.
>Until just a few years ago, the satellite communication system used by jetliners didn't include data on an aircraft's location in the pings, the electronic equivalent of handshakes used to establish initial contact.
http://www.pprune.org/rumours-news/535538-malaysian-airlines...
Owners of this patent [1] were all aboard the plane. The only remaining owner is Freescale Semiconductor, owned by Rothschild family.
[1] http://truthnewsinternational.files.wordpress.com/2014/03/us...
ok.
And furthermore, what motive would someone have to knock off the inventors when they no longer even own the patent? If you look in the document, you can see that it has an single Assignee, Freescale Semiconductor. When a patent has been "assigned", the original inventors give up any proprietary rights in the invention to the Assignee, which is the normal process with corporate patents.
Moving around the plane opening hatches and tinkering with equipment requires there to be at least a few people. One to do the work, one inside the cockpit managing the flight and one looking after the passengers. All of them you would assume would have guns to keep the passengers from simply rushing them.
Getting multiple weapons past security surely means an inside job. And then what is the motivation for multiple people wanting to hijack this particular plane ?
Yes, of course -- any piece of electronic equipment might (a) begin to misbehave and interfere with other equipment or produce misleading results, or (b) catch fire and emit smoke into the flight deck, or (c) both. It's common sense to have a way to disable any piece of equipment on short notice.
I played a small part in the design of NASA's Space Shuttle many years ago, and we definitely kept the possibility of equipment failure in mind at all times.
> It seems like they should make it more difficult than just throwing a breaker in the cockpit.
On board an aircraft, the pilot has the highest authority. You don't expect to have to protect the aircraft from him -- more the reverse. That is why, when a pilot goes crazy, the results are usually catastrophic.
http://feedingnew.wordpress.com/2014/03/13/mystery-of-missin...
I don't have direct experience with the 777, but do with the 787 and other aircraft systems. I am not aware of any wireless sensors. There are a lot of sensors which communicate with the various computers over multiplexed wired data buses.
ARINC 429 is a legacy, but still heavily used, digital data bus.
ARINC 629 is used on the 777.
ARINC 664 is used on the 787 (and Airbus A380).
The military systems and some commercial systems also use MIL-STD-1553 and other digital busses.
All wired.
Not even time to mayday.
The problem with this "theory" is that it doesn't explain all the evidence. Sure, a hijack would have to be way more complicated than a mid-air explosion, just like a nuclear power plant would have to be way more complicated.
But a complicated set of transponders turning off with sudden radio silence is exactly what happened. Plus, if it was a mid-air explosion - where are the pieces?
This is ridiculous. An elaborate conspiracy to fool people into believing in nuclear power isn't simple at all. Not to mention events like Chernobyl
What you've done is make a wild assumption, that would require a lot more assumptions to be true in order for your exploding plane theory to be true. Which is about as far away from Occam's Razor as you can get.
I wish people would stop saying "Occams Razor" and then inserting any old jibber they want, because they feel they've apparently qualified it by saying Occams Razor, even though they have no idea what Occam's Razor actually is. It's lazy and hollow reasoning.