Originally Posted by
HUD Engineer
I don't think it was quite as you suggest, but with reported loss of primary displays and reported loss of control it is instructive to note that in the anticipated situation for which FAA-2015-0936 Interim Airworthiness Directive that at a predictable point in time the 4-off Generator Control Units could simultaneously go into Fail-safe mode and deprive the aircraft of AC electrical power, it "could result in loss of control of the airplane" and could occur regardless of flight phase That related to exceeding a 248 day powered period, so the AD instructed that power was removed at least every 120 days.
Regarding the 120 day maintenance action interval, note that in 2020, FAA-2020-0205 (not an Interim AD) was raised due to counter/timers associated with the Common Core System, that could affect data integrity after 51 days, and a power-down repeat interval of 25 days was specified in B787–81205–SB420045–00, Issue 2.
Sweet!
Sounds like they are running Windows OS. At one of my customers, the boss bought an accounting system running on windows, using SQL Server als Database. Three years ago they were forced to add a POS (PointOfSales) module issuing the cryptographically linked cash-receipts as per government anti-fraud-laws.
Since then, every 3 weeks +/- one week one of the 10 cashier systems would lock up (while cash customer is waiting).
Manufacturer "looked into it" didn't find anything to fix and installed a Sunday morning reboot of application and database server,
problem "solved the Microsoft way".
The merchandise handling system (the one I wrote) runs 24/7 on an ORACLE database on Linux (yes, open source). Current uptime is 300 days (e.g. since last hardware failure). In my 35 years of experience I cannot imagine any problem on Linux that would "require" a server reboot to clear.
One of the biggest Austrian Banks I do consulting for is running slightly north of 300 ORACLE Databases on Linux, including multi terabyte trading systems,
and not one of them "needs" periodical reboots.
Lesson to learn:
any system that needs regular reboots to keep working contains abysmal software not thorougly tested.
If after start, cruise and landing an FMC accumulates "debris" data that needs to be cleared by reboot the software is crap,
not thorougly cleaning up data traces after completing the "landing" phase.
That could be because the designing engineers were idiots, or because cost cutting mangement did not provide them with ample resources for thoroughly testing before claiming "read for business".
You may guess what my experience in that field is.
hint:
I've witnessed a european airlive got bust because clueless management went from hierarchical database system to relational database (e.g. total redesign) w/o having their own engineers lead in that process and impatiantly declaring "transition done" when it wasn't.