The Boeing 787 Dreamliner represents one of the biggest technological shifts in commercial aviation history. Unlike previous generations of aircraft that relied on dozens of independent avionics computers, the 787 was designed around a highly integrated digital architecture where many critical functions share common computing resources. This approach improved efficiency, reduced hardware weight, and enabled advanced aircraft capabilities. However, it also created a new operational reality: airlines cannot independently modify the aircraft’s core software without Boeing’s direct involvement.
The reason is not simply that Boeing controls the software. The deeper issue is that the 787’s software is legally and technically part of the aircraft itself. Its code is included within the aircraft’s FAA-certified type design, meaning any major modification must follow the same regulatory pathway as a physical change to the airframe or a flight-control component.
For airlines, this creates a unique relationship with the manufacturer. When a software problem appears, operators cannot simply hire developers, rewrite code, test the update, and upload it into their aircraft. Instead, the issue must move through Boeing’s engineering organization, certification procedures, and regulatory approval process before a new software package can enter service.
How the Boeing 787 Common Core System Changed Aircraft Software
Older commercial aircraft such as the Boeing 767 and Boeing 777 were built around a federated avionics architecture. Each major aircraft function typically had its own dedicated computer. The flight management system operated on one computer, the autopilot used another, the weather radar had its own processor, and aircraft warning systems relied on separate avionics units.
This design created clear boundaries between systems. If engineers needed to update the flight management software, they could focus on that specific avionics computer without significantly affecting other aircraft functions. The hardware and software were separated into individual modules that could be independently developed, tested, and certified.
The 787 Dreamliner moved away from this traditional approach. Boeing introduced the Common Core System (CCS), a centralized computing platform that allows multiple aircraft functions to run on shared hardware. Instead of relying on many isolated computers, the aircraft uses fewer but more powerful computing modules capable of hosting multiple software applications.
This architecture brought major advantages. The aircraft could reduce equipment weight, improve processing capability, simplify wiring, and support more advanced digital functions. The 787’s designers created an aircraft where software became a central element of how the airplane operates.
However, this integration also created a significant challenge. When multiple functions share the same computing environment, a change to one software component can potentially affect other applications running on that platform.
For example, an update to one application may influence processor allocation, communication pathways, data handling, or interactions between different aircraft systems. Because of this interconnected structure, airlines cannot treat core software updates as isolated maintenance tasks.
The 787’s software environment is therefore more similar to updating the operating system of a highly integrated computer platform rather than replacing software inside a single independent device.
Why 787 Software Is Considered Part of the Aircraft’s Type Certificate
The most important reason airlines cannot independently update the 787’s core software is certification.
When an aircraft manufacturer develops a new aircraft, regulators approve not only the physical structure but also the systems and software that define how the aircraft operates. For the 787, the software configuration installed on the aircraft forms part of Boeing’s approved type design.
This means the software is not treated like a normal commercial software product. Airlines do not own unrestricted access to the aircraft’s source code or system architecture. Instead, they operate an aircraft configuration that has been certified by aviation authorities.
Aviation software must meet strict development requirements under standards such as DO-178, which governs the creation and verification of airborne software. Certification does not only examine whether the software performs its intended function. It also examines whether the software behaves safely under abnormal conditions.
On a traditional aircraft, certification usually focuses on individual avionics units. A flight management computer is approved as a specific component, and its software is evaluated within that hardware environment.
The 787 requires a broader certification approach because the Common Core System combines multiple applications on shared infrastructure. Regulators must consider not only whether each application works correctly but also how different applications interact with each other.
A modification to the 787’s core software therefore becomes a design change rather than a routine airline maintenance action. Boeing must analyze the modification, conduct engineering reviews, complete testing, prepare certification documentation, and receive regulatory approval before operators can install it.
The airline may identify the problem, provide operational data, and participate in evaluations. However, the responsibility for creating and certifying the solution remains with Boeing.
What Airlines Can Change on the Boeing 787
Although airlines cannot rewrite the aircraft’s core software, they are not completely powerless over the 787’s digital systems.
Boeing provides operators with predefined configuration tools known as Airplane Software Options. These allow airlines to customize certain aircraft features without changing the fundamental software architecture.
These options exist within boundaries that Boeing and aviation regulators have already approved. Airlines can select from available configurations, but they cannot create entirely new software functions.
Examples of configurable areas may include:
- Cabin management settings
- Operator-specific display configurations
- Certain crew alerting preferences
- Passenger service features
These adjustments allow airlines to tailor aircraft operations to their fleet requirements while maintaining certification compliance.
However, the distinction between configuration and modification is extremely important. Selecting a Boeing-approved option is not the same as writing new aircraft software.
An airline choosing a certified setting is similar to selecting a feature from a manufacturer’s menu. The airline is deciding how to use an existing capability, not changing the underlying system.
Critical functions remain under Boeing’s control. Flight-control logic, autoflight behavior, engine management software, and safety-related aircraft functions cannot be modified independently by operators.
The boundary exists because these systems directly affect aircraft safety. A small software change in a noncritical passenger feature may have limited consequences, but a change affecting flight operations requires extensive analysis and certification.
The 51-Day Boeing 787 Software Problem
One of the clearest examples of why airlines depend on Boeing for software solutions was the Boeing 787 51-day power cycle issue.
In 2020, the FAA issued an airworthiness directive requiring operators to completely power down their 787 aircraft at least once every 51 days. The issue involved the aircraft’s Common Core System and its ability to monitor outdated data.
During Boeing testing, engineers discovered that after 51 days of continuous operation, a function responsible for detecting stale information could stop working correctly.
The potential consequences were serious. If outdated information entered the aircraft network without proper detection, pilots could potentially receive incorrect indications related to aircraft parameters such as:
- Airspeed
- Altitude
- Aircraft attitude
- Engine information
The FAA identified possible safety concerns because inaccurate information displayed as valid data could affect pilot decision-making.
The temporary solution was simple: shut the aircraft down completely and restart the system. A full power cycle reset the software monitoring function.
However, the solution highlighted the larger issue. Airlines could not independently rewrite the affected software or create their own permanent fix. Operators had to follow the airworthiness directive while Boeing developed and certified a long-term solution.
A similar situation occurred in 2015 when Boeing addressed another software-related issue involving the aircraft’s Generator Control Units (GCUs). The problem involved a software counter that could eventually overflow after extended operation, potentially causing the generators to enter a failsafe mode.
Again, airlines could not simply install their own software correction. Boeing had to develop the fix, validate it, obtain approval, and provide operators with an authorized installation procedure.
These events demonstrate how software problems on modern aircraft are handled differently from software problems in ordinary technology products. An airline cannot simply download a patch and restart the system.
Why Airlines Must Depend on Boeing for Major Software Fixes
For airlines operating large fleets of 787 aircraft, this dependence creates both advantages and challenges.
The advantage is consistency. Boeing has access to the original aircraft design data, software architecture, testing facilities, and certification expertise. The manufacturer understands how different systems interact and can develop solutions that maintain regulatory compliance.
However, the disadvantage is that airlines have limited control over the timeline. Even if an operator identifies a software issue quickly, it cannot independently solve the problem.
The process typically follows a structured path. The airline reports the issue to Boeing. Boeing engineers investigate the cause and develop a solution. The manufacturer then performs testing and prepares the necessary documentation. After regulatory approval, Boeing releases the update through an official service bulletin or approved procedure.
For an airline operating dozens of 787s, this means a software issue may remain unresolved for an extended period while certification work takes place.
An airline’s own engineering department may be highly capable, but it cannot bypass the aircraft manufacturer because the software is tied directly to the aircraft’s certified design.
This relationship differs significantly from older aircraft programs. Operators of older jets could sometimes work directly with avionics manufacturers to manage individual component updates. The 787’s integrated architecture places Boeing at the center of the process.
The Future of Software-Defined Commercial Aircraft
The Boeing 787 is part of a broader industry movement toward software-defined aircraft.
Modern aircraft increasingly rely on integrated computing platforms, advanced networks, and centralized software systems. The same trend can be seen in aircraft such as the Airbus A350, which also uses a highly integrated avionics architecture.
Future aircraft designs are expected to rely even more heavily on shared computing platforms. These systems will provide greater efficiency, improved automation, and expanded capabilities.
However, they will also increase dependence on manufacturers for software management. As aircraft become more like flying computers, software updates will become increasingly connected to certification, safety analysis, and regulatory oversight.
The inability of airlines to independently update the Boeing 787’s core software is therefore not simply a Boeing-specific restriction. It is a consequence of modern aircraft design, where software is no longer just a replaceable component but a fundamental part of the aircraft’s identity.
The 787 Dreamliner’s Common Core System delivers enormous technological benefits, but it also changes the relationship between airlines and manufacturers. In this new era of aviation, keeping an aircraft updated is no longer only a maintenance responsibility. It is a carefully controlled engineering process that requires the manufacturer’s expertise and regulatory approval.
