I work on avionics. It's a great job, except you have no idea when or how things can go drastically wrong. We had a bug in our weather data parser that didn't surface in 2 years of constant testing. The weather receiver is only supposed to give data for the continental United States, but we occasionally would get a Temporary Flight Restriction for Iraq, which worked fine.
One day, we got a report from a customer that his panels rebooted twice, in the clouds. All signs were pointing to the weather receiver. I feverishly looked through the code and eventually found the problem.
We were getting a TFR for an air show.. in Guam. I knew that we handled the eastern hemisphere properly, the Iraqi TFR's worked fine.. The data looked something like "....151.235E10.1235N...".. We eventually determined that the floating point value parser was treating the E as scientific notation and blowing up. It worked fine on my PC (glibc), but not on the device (newlib).
So what happened? In "2 years of constant testing", you ... didn't test it on the device? Didn't try codes outside the area it was supposed to work in? Is there a weather data standard and you didn't meet it, or is there one but it's not always followed, or is there none and you have to do as well as you can?
A little bit of all those things -- it worked just fine, on the device, for 2 years, including the occasional eastern hemisphere TFR. It only happened with a TFR that was close to the international date line which made the ascii -> float conversion run off the end of the string. I admit I didn't test that eventuality -- but I was using a C library function that's been in constant use for over 30 years.
There's no real weather data standard, XM Weather is a collection of formats (nexrad radar comes over as a bitmap, weather reports are METAR encoded).
The Temporary Flight Restrictions are in XML, well, not really XML, it's a really nasty format designed by Jeppesen were you basically have to write your own XML parser because they made it impossible to parse with a standard XML parser.
It just goes to show that even when you test the hell out of something, you can still get blind sided by something you never thought of, but once it happens, it seems really obvious.
Remember the problem the F-22 had going across the international date line -- that code was a lot less tested than mine in that regard -- but they just didn't think about it.
One day, we got a report from a customer that his panels rebooted twice, in the clouds. All signs were pointing to the weather receiver. I feverishly looked through the code and eventually found the problem.
We were getting a TFR for an air show.. in Guam. I knew that we handled the eastern hemisphere properly, the Iraqi TFR's worked fine.. The data looked something like "....151.235E10.1235N...".. We eventually determined that the floating point value parser was treating the E as scientific notation and blowing up. It worked fine on my PC (glibc), but not on the device (newlib).