I might be wrong, but what I had heard back then was that the Airbus software is based on Windows NT. Will investigate. I also have heard stories about BLUE screens!
The internet is full of photoshopped images of Airbus cockpits showing bluescreened (windows blue screen of death, known as BSOD) displays, but I know they are fake because Airbus must have the technology (accessible via google) for customising the blue screen 
Yes, and i did not have my infos from “google” but from better sources :-)
There is a big difference between a nav display and the attitude indicator.
Yes but even a failing nav display can cause elevated workload. I know because I had to restart my certified panel mount GPS twice, in flight.
Also, a nav display showing wrong data without fail indication can be dangerous, such as a frozen display you don’t notice immediately that it is frozen.
Yes, and i did not have my infos from “google” but from better sources :-)
You mean friends making practical jokes at your expense? 
Also I cannot understand how anybody can logically prove that any program with more than about (say) 100 instructions will work in all situations.
You can’t. What DO178 seems to mandate is that you create high level requirements, then lower level requirements, and so on. And then you trace back, first from the object code to the source code (i.e. which assembly instruction implements which source construct), then from source code to lowest level requirements, and so on upward the hierarchy. DO178 even gives you the minimum number of requirements you need to prove for each design assurance level.
I fail to see how you could do even the trace back from object to source code for windows, even ignoring the fact that the shrink wrap license actually forbids you doing this, except for the lowest design assurance level E, which is typically used for the inflight entertainment equipment and requires 0 proven requirements. Maybe Avidyne Glass is certified as IFE?
And yes, most if not all ANSP/Eurocontrol systems wouldn’t be certifiable under DO178 for any design assurance level other than E. They seem to have the advantage that the regulators don’t quite seem to understand what they are doing.
I fail to see a big difference between a complex state machine implemented in software versus a complex state machine implemented using Verilog or VHDL and run on a field programmable gate array. Yet the former requires full DO178 paperwork exercise, while the latter until recently just had to be put into the climate chamber and verified it worked from 15 to 50 degC (or some different, but much less stringent temperature range compared to industrial electronics). It seems that only very recently regulators noticed this.
Wasn’t a warship left floating out of control because Windows crashed?
http://www.wired.com/science/discoveries/news/1998/07/13987
Even if most people don’t use Linux/Apple/Other Unix type products, the competition was
very good for Windows.
The warship was testing its new Smart Ship system, which uses off-the-shelf PCs to automate tasks that sailors have traditionally done themselves.
That (article from 1998) was just stupid. One cannot use an off the shelf PC for anything critical – regardless of what O/S is running on it. There are loads of reasons but e.g. a defective peripheral device can generate continuous interrupts or DMA requests and just hang up the whole thing.
I suppose you could sidestep those issues by disabling most of the peripherals but then you lose most of the “cooked and ready to eat” I/O which any “full” O/S gives you and which is most of the reason you are using a PC in the first place.
most if not all ANSP/Eurocontrol systems wouldn’t be certifiable under DO178 for any design assurance level other than E. They seem to have the advantage that the regulators don’t quite seem to understand what they are doing.
True – AFAICT all ATC stuff runs on normal PCs running some form of unix. That is what they have at Eurocontrol – I have been there. Desktop workstations etc. Nothing special. And a load of boffins who know stuff like “rm -r” and “ls -l”
I fail to see a big difference between a complex state machine implemented in software versus a complex state machine implemented using Verilog or VHDL and run on a field programmable gate array. Yet the former requires full DO178 paperwork exercise, while the latter until recently just had to be put into the climate chamber and verified it worked from 15 to 50 degC (or some different, but much less stringent temperature range compared to industrial electronics). It seems that only very recently regulators noticed this.
As an ex FPGA designer I find that very funny, and completely unsurprising.
You could do some great temperature dependent stuff in FPGAs. Basically the whole concept of FPGAs works only if you use the common clock net, and make sure that the clock frequency is slower than the worst case D to Q propagation (etc). The moment you start clocking anything from anything other than the common clock net, all bets are off. You can make designs that work, but not at higher temperatures because the D to Q etc propagation delays get longer. Or not at low temps, for other reasons…
When this came to light, Xilinx got all pompous and said that nobody should be doing designs “the wrong way” but in reality almost everybody does. To do it correctly, you need a different approach and you end up doing stuff in sometimes obscure ways.
The problem with using the common clock net is that you get a high power consumption – because the whole chip is going up and down at 50MHz or whatever. You really would not do that if you plant o go to an ASIC (custom silicon) one day.
Hello everyone. I am very new here. This is my first post. I took the photo. It is indeed real. The EX5000 MFD is based on an embedded version of Windows NT. It’s shoddy software engineering by Avidyne and has nothing to do with Windows. My friend, who piloted the SR22 contacted Avidyne. Here is their response:
“IPL is the Intel Image Processing Library that the E1 MFD uses for display of terrain. Apparently something caused it to choke here. We see this message very very rarely. in fact, I can’t recall the last time.
If this just happened once, and the pilot’s been flying around in this area for a while, I’d say it may be an error in the compact flash, that data wasn’t read out for display as it should have been.
But if it can be reproduced by flying in a certain area with the display at a certain range (I see you’re at 2 nm in the jpeg), then maybe there’s an error in the terrain data. I think this is unlikely – errors in our terra data usually show up as missing tiles or a garbled terrain display, not an IPL issue.
I talked to Tech Support, and they see these windows dialogs every once in a while. They replace the customer’s CF and the problem goes away. So that’s our recommendation."
Link: http://forums.avidyne.com/forum_posts.asp?TID=355&title=error-message-on-mfd
Regards.
I visited Seattle TRACON last month on a 2 hour tour. Windows logos everywhere.
boffins who know stuff like “rm -r” and “ls -l”
Thank you. If ever I want a new nickname it shall be “Peter’s Boffin”
