Boeing 787’s 248-Day Bug: When an Integer Counter Could Shut Down Electrical Power
The 787's generator control units shared a software counter that could overflow after 248 days of continuous power, sending all four main units into failsafe mode together.
The 787’s electrical architecture made software part of aircraft power generation
The Boeing 787 uses a more-electric architecture than earlier airliners, relying heavily on electrically driven systems and multiple high-capacity generators. Generator control units coordinate those power sources and protect the electrical system. In 2015 the FAA issued an airworthiness directive after Boeing identified a software counter inside the generator control units that could overflow if an airplane remained powered continuously for 248 days.[1] The extraordinary detail was not merely that one controller could fail. All four main GCUs could reach the same counter limit together.
Redundant hardware can still share one software clock
If independent devices run identical software, start at the same time, and count the same event, a deterministic bug can synchronize their failures and defeat redundancy.
The failure mode could remove all alternating-current electrical power
The FAA stated that simultaneous counter overflow would cause the generator control units to enter failsafe mode and could produce loss of all AC electrical power, potentially leading to loss of control of the airplane.[1] That severity transformed what sounds like a mundane uptime bug into a regulatory safety issue. A counter with a finite range is not automatically dangerous, but it becomes dangerous when rollover behavior is not designed and tested as part of the system’s operational lifetime.
Calendar time can be an input to software even when no clock is visible
Long-running embedded systems accumulate ticks, cycles, messages, or scheduler intervals. Testing must consider what happens when those internal quantities wrap months after deployment.
The original mitigation was surprisingly simple: reboot the electrical system
AD 2015-09-07 required operators to periodically deactivate airplane electrical power before the 248-day threshold was reached.[1] Power cycling reset the counters, preventing the synchronized overflow. This is a familiar workaround in ordinary computing, but aviation regulation made it a formal repetitive maintenance task because the consequence of forgetting it was unacceptable. The workaround bought time for a permanent software correction.
The permanent fix required new generator-control software
The FAA later superseded the repetitive power-cycle requirement with an airworthiness directive requiring installation of new GCU software on affected airplanes.[2] The proposed corrective rule explained that Boeing had developed a modification to eliminate the unsafe condition rather than relying indefinitely on operational resets.[3] This progression—from containment to design change—is a useful safety pattern. Immediate mitigations can reduce risk while a verified permanent fix moves through certification.
A workaround should have an expiration strategy
Operational procedures are vulnerable to omission and organizational drift. When the defect is deterministic and fixable in software, the long-term solution should remove the hazardous state rather than merely schedule around it.
The bug exposed a common-mode weakness in redundancy
Aircraft electrical systems contain multiple generators precisely so one failure does not remove power. But identical control units with synchronized state can form a hidden common-mode dependency. The four units looked redundant physically while sharing the same defect logically. Safety analysis therefore has to ask whether redundant channels are truly independent in implementation, timing, configuration, and failure triggers.
Long-uptime testing is difficult because ordinary test schedules are short
A 248-day condition is inconvenient to reproduce in real time. Engineers typically accelerate counters, simulate time, or instrument software to exercise rollover boundaries. The 787 case is a reminder that every bounded counter has a future edge. Boeing’s own description of the 787 emphasizes the aircraft’s extensive electrical architecture, making software behavior in power control especially consequential.[4] Test plans need explicit boundary analysis rather than waiting for elapsed time to reveal overflow naturally.
“It would take months to happen” is not a safety argument
Airplanes, data centers, satellites, and industrial systems can stay powered far longer than developers expect. Rarely exercised uptime states eventually become normal somewhere in a large fleet.
The incident belongs to a wider history of 787 power-software evolution
Boeing has continued to use flight-test aircraft to validate power-distribution software changes, underscoring how deeply software is embedded in the Dreamliner’s electrical design.[5] The 248-day defect was not evidence that software-controlled power is inherently unsafe; it was evidence that digital control creates new failure dimensions alongside traditional electrical faults. Counters, synchronization, update versions, and reset behavior become airworthiness concerns.
Why the 248-day bug matters beyond one airplane
This case is a nearly perfect example of deterministic common-mode failure. Engineers built physical redundancy, but identical software state allowed several channels to fail together. The lesson applies to clustered servers, redundant PLCs, automotive controllers, and safety computers as directly as it applies to aviation.[1][2]
Resilience requires diversity of failure, not merely duplication of components. Teams should inventory shared counters, time bases, certificates, configuration files, dependency versions, and update mechanisms across supposedly redundant channels. A system can contain four controllers and still have one failure mode if every controller executes the same latent defect at the same moment. The 787’s 248-day counter turned that abstract systems principle into an unusually memorable maintenance directive.
Works Cited
- 01Federal Register — FAA AD 2015-09-07 for Boeing 787 Generator Control Units public-inspection.federalregister.gov
- 02
- 03Federal Register — Proposed Superseding AD for Boeing 787 GCU Software public-inspection.federalregister.gov
- 04Boeing — 787 Dreamliner by Design boeing.com
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.