As an IT professional and scholar I just want to bang my head at the table when I read this kind of thing.
There must be something in the 284 days… e.g. an unsigned long integer incremented once a second 
The first thing that actually came to mind when I first read this was a memory leak, but some kind of counter that increments and wraps around is another likely cause.
A memory leak would suggest the use of malloc() or some other dynamic memory allocation scheme, which is a totally mad crazy nutty idea in any application which needs to keep running.
Anyway, aren’t airliners rebooted before every flight? One US regional pilot (I was talking to in the cockpit, post-landing) told me they are required to power cycle the whole panel before each flight. But probably not the whole aircraft…
Anyway, aren’t airliners rebooted before every flight?
Not necessarily. If you have an APU or a ground power connection, then some buses may remain powered all the time. The GCUs on “my” little jet are connected to the main battery bus (which can also be powered from the external power connector) and as long as you don’t turn that bus off – by removing external power and switching the battery to OFF – the GCU will continue to operate. But I would say that 286 days of continuous operation is totally unrealistic for any aeroplane. This would mean no maintenance during which power has to be removed for 3/4 of a year? No way. So I can understand why the designers of this software didn’t look any further than integers for storing their timer signals. For me however, the real bug in this software is the behavior after the counter overflows: Instead of simply restarting, it puts the units into failsafe mode.
The EASA guy that came up with the idea that two Garmin 430 may not be interconnected unless they have different firmware versions will be very happy.
I once owned a company doing standby server technology. We would have a cold standby server that would replicate all memory and disk changes happening on the production server and in case the production server went down, could automatically take over. In cases where there was disk/memory corruption and then a failure, our system would reliably mirror the corruption. Customers paid a lot of money for redundancy because it was a requirement (banks mostly) but all they got is a system that in some cases would just produce the same error on both systems
Well I wasn’t far off…
Thanks for the link, what next.
284 days is awfully close to 24576000 in seconds. It is a common quartz crystal frequency, used to get useful baud rates in microcontrollers.
The EASA guy that came up with the idea that two Garmin 430 may not be interconnected unless they have different firmware versions will be very happy.
Did EASA allow 2 × GNS if they had different firmware? AFAIK they ban 2 × GNS regardless of firmware versions. There is a way around it e.g. Socata did it under the TB20 GT Type Certificate. The non-TC route involved a very expensive Part 21 design process which not many people did, though I recall a certain UK avionics shop did sell a paperwork package for about £2000 which allowed it, on a specific aircraft type.
There are plenty of 2×GNS430 setups in Switzerland.
Re continuous runnning, on top of maintenance I think it’d be hard to schedule 284 days without a single night-stop. That would be impressive capacity utilisation.
I think it’d be hard to schedule 284 days without a single night-stop…
Theoretically, you could leave the buses powered during a night stop by using ground power. But why would anybody do that?
