dailynewsnblog
The Boeing 787 runs on a software architecture that is fundamentally different from any commercial aircraft that came before it. Rather than dozens of independent avionics computers each running their own embedded software, the 787 consolidates most of its major functions onto a shared computing platform called the Common Core System, with approximately 300 Loadable Software Airplane Parts distributed across roughly 1,400-1,500 locations on the aircraft. The software is not a separate product from the airframe. It is part of the aircraft’s FAA type certificate.
That distinction has a practical consequence that affects every airline operating the type. When a software issue is discovered on the 787, the airline cannot develop or install a fix independently. The software is certified as part of Boeing’s type design, which means any change to core system code must go through Boeing’s engineering organization and the FAA’s approval process before it can be loaded onto an in-service aircraft. Here is how the 787’s software architecture works, what airlines can and cannot modify on their own, and what happens when a bug is found that the operator has no ability to fix.
How The 787’s Software Architecture Differs From Older Aircraft
On older commercial aircraft like the Boeing 767 or 777, each major system runs on its own dedicated computer. The flight management system has its own box. The engine indicating and crew alerting system has its own box. The weather radar, the autopilot, the communication management system, and dozens of other functions each run on separate, self-contained avionics units installed in the electronics bay beneath the cockpit. If one box fails, the others continue operating independently. The architecture is modular by design, with each unit developed, certified, and maintained as a standalone piece of hardware running its own embedded software.
The 787 replaced that model with an integrated architecture called the Common Core System. Rather than dozens of independent computers, the CCS uses a smaller number of shared computing modules that host multiple aircraft functions as software applications running on common hardware. The flight management function, the display processing, the maintenance computing, and other systems share the same processing infrastructure rather than each occupying a dedicated box.
The practical difference for the airline is that the 787’s systems are interdependent in ways that older aircraft’s systems are not. On a 767, updating the flight management software is a self-contained task that affects only the FMS computer. On the 787, changing one software application on the Common Core System can affect other applications running on the same hardware, because they share processing resources, data buses, and in some cases input and output pathways. That integration is what makes the 787 more capable and more efficient than its predecessors. It is also what makes the software impossible to modify without the manufacturer’s involvement.
Why The Software Is Part Of The Aircraft’s Type Certificate
The software running on the 787’s Common Core System is not a product the airline purchased separately from the aircraft. It is part of the aircraft’s FAA type certificate. When 
Boeing certified the 787, the software configuration was validated as a component of the overall type design, tested and approved alongside the airframe, engines, and physical systems as an integrated package. The FAA’s approval covers not just the hardware but the specific software versions running on it, because on the 787 the software defines how the aircraft behaves in a way that previous aircraft types did not require.
On a conventional aircraft, software certification covers individual avionics units. The FMS software is certified for the FMS box. The autopilot software is certified for the autopilot computer. Each unit goes through its own approval process under DO-178, the standard that governs airborne software development, and the certification applies to that specific unit in isolation. On the 787, the Common Core System hosts multiple functions on shared hardware, which means the certification covers the interaction between those functions as well as each function individually. A change to one application can affect how the shared platform allocates processing resources to other applications, which makes the certification scope broader than on any previous commercial aircraft.
The result is that modifying the 787’s core software is not an airline maintenance task. It is a design change to the aircraft’s type certificate. Any modification to the code governing flight controls, displays, the Common Core System, or safety-critical functions must flow through Boeing’s engineering organization, undergo the required analysis and testing, and receive FAA approval before it can be loaded onto an in-service aircraft. The process typically follows the same path as a physical design change: Boeing issues a service bulletin, the airline incorporates it during maintenance, and the FAA validates the change through its oversight of Boeing’s delegated authority.
What Airlines Can And Cannot Change On Their Own
Airlines are not locked out of the 787’s software entirely. Boeing provides a set of tools called Airplane Software Options that allow operators to configure certain aspects of the aircraft’s behavior within a pre-certified envelope. These are not open-ended customization tools. They are a defined set of selectable settings, dozens of options covering areas like cabin management systems, crew alerting preferences, and operator-specific display configurations. The airline selects from the available options, and the resulting configuration produces a custom set of Loadable Software Airplane Parts specific to that operator.
Even within that bounded set of choices, the airline cannot simply load the software and fly. The resulting custom LSAPs must go through a regulatory operational acceptance process before they can be installed on the aircraft. The airline submits its selected configuration, the regulatory authority reviews it against the certified envelope, and the software is approved for that specific operator’s fleet. The process is faster and less expensive than a full type design change, but it is not self-service. The airline is choosing from a menu Boeing created and certified in advance, not writing its own code.
The boundary between what the airline can configure and what it cannot is defined by criticality. Cabin lighting schedules, passenger announcement settings, and operator-specific display preferences fall within the configurable range. Flight control laws, engine management logic, autoflight behavior, and anything classified as safety-critical under DO-178 does not.
The 51-Day Reboot Problem
In April 2020, the FAA issued an airworthiness directive ordering all 787 operators to completely power down their aircraft at least once every 51 days. Boeing had identified during laboratory testing that the Common Core System’s stale data monitoring function stops working after 51 days of continuous power. Without that function, the CCS can no longer distinguish between current and outdated data on the common data network, which means misleading airspeed, altitude, attitude, and engine operating indications could be displayed to the pilots as valid readings. The stall warning horn and overspeed horn also stop functioning. The FAA classified the potential consequences as “several potentially catastrophic failure scenarios.”
The fix was to turn the aircraft off and back on. A complete power cycle resets the counter and restores the stale data monitoring function. Commercial aircraft routinely stay powered on for weeks at a time, with ground power connected overnight while maintenance, cleaning, and catering take place between flights. Crews change at airports without the aircraft ever being shut down. The 51-day limit forced airlines to schedule deliberate power-down events within their maintenance planning, taking the aircraft offline specifically to reboot its computing systems. It was not the first time the 787 required mandatory power cycling. In 2015, the FAA had issued a similar directive after Boeing discovered that the generator control units’ software counter would overflow after 248 days of continuous operation, causing the GCUs to enter failsafe mode and stop producing electrical power.
Neither the 51-day nor the 248-day issue could be resolved by the airlines themselves. Both required Boeing to develop a certified software fix, test it, issue a service bulletin, and obtain FAA approval before airlines could install it. In the interim, operators followed the airworthiness directive and rebooted their aircraft on schedule. The 51-day directive remained in force for years while the permanent fix worked through Boeing’s certification process.
What This Means For Airlines Operating The 787
The practical consequence of the 787’s software architecture is that airlines operating the type are dependent on Boeing for every core system update in a way that operators of older aircraft types are not. On a 767 or 777, an airline’s engineering team can work directly with individual avionics suppliers to source software updates for specific boxes, coordinate the installation with its own maintenance organization, and manage the regulatory approval through its existing relationship with the FAA or its national authority. The work is distributed across multiple suppliers and the airline retains a degree of control over the timing and prioritization of each update.
On the 787, that relationship is centralized through Boeing. A software issue affecting the Common Core System cannot be resolved by contacting the hardware supplier directly, because the software is certified as part of Boeing’s type design rather than as an independent product. The airline submits the issue to Boeing, and the planemaker’s engineering organization develops the fix. Boeing manages the certification process and issues the service bulletin that authorizes the airline to install the update. The airline’s role is to report the problem and wait for the solution. On a fleet of 30 or 40 787s, a software issue that takes Boeing 18 months to certify a fix for is an issue the airline lives with for 18 months regardless of its own engineering capacity.
The 787’s architecture represents the direction the industry is moving. The A350 uses a similar integrated avionics approach, and future aircraft programs are expected to push further toward software-defined systems running on shared computing platforms. The dependency on the manufacturer for core software changes is not a flaw specific to Boeing or the 787. It is a structural consequence of building aircraft where software is part of the type certificate rather than a replaceable component inside an independent box.
