Image: © Steve Jurvetson | Wikimedia CC-BY 2.0
From flight management computers that precisely calculate optimal routes to enhanced ground-proximity warning systems (EGPWS) that prevent terrain collisions, software has become a key enabler of the safety of air operations. This growing dependence on digital systems requires the same level of reliability and safety assurance that applies to hardware systems.
Unlike mechanical components that fail predictably through wear and fatigue, software presents a fundamentally different risk profile. It does not degrade over time, but it can harbor latent defects that manifest only under specific, rare conditions. This reality requires aircraft operators to treat software as an important item of continuing airworthiness management. Moreover, as artificial intelligence (AI) and machine learning technologies enter the industry, so, too, does the challenge of how to regulate and ensure the safety of AI-powered non-deterministic systems that learn and adapt.
Today’s aviation software landscape is characterized by increasingly sophisticated manufacturer controls, with protocols that require operators to become certified to manage onboard software or rely on manufacturer-provided services. This shift reflects a broader industry recognition that software management demands specialized expertise and presents cybersecurity risks that legacy approaches cannot adequately address.
Software Governance
According to Transport Canada (TC), software regulation upholds stringent standards similar to those that govern structural components. “Software goes through a rigorous regulated process to prove that it performs its intended function with a level of confidence in safety that complies with airworthiness requirements,” a TC representative says.
Software is regulated by different methods than those applied to structural components but with the same rigor, the European Union Aviation Safety Agency (EASA) says. Janet Northcote, EASA chief communications officer, adds, “Structural components are tested for physical strength and fatigue, while software … is assured through development and verification processes, aligned with the safety objectives of the various aircraft certification specifications … dealing with equipment, systems, and installations — and other similar rules.”
Aircraft operators are seeing an increase in restrictions — on software download, upload, and handling in general, says Sara Zerbini, continuing airworthiness manager at an independent EASA continuing airworthiness management organization. “For example, some manufacturers allow registered users to simply download software directly from their webpage, while some others are introducing protocols that effectively require operators to become certified in order to manage onboard loadable software,” she says. “Aircraft operators may in some cases be obliged to use the manufacturer’s own service. In such cases, manufacturers set an annual fee, and in return, provide aircraft operators with support for the software they install on board. This also covers protection against hacking and similar risks, and the landscape continues to evolve.”
Some of these measures are not new. For instance, when it comes to the flight management computer’s navigation database, manufacturers have long provided a letter of approval to certify that the database contents comply with applicable standards and match the data published in navigation charts, according to Zerbini. “This represented one of the first steps toward software-related compliance. Some manufacturers have taken further measures for systems like … EGPWS. In those cases, operators download the data from the manufacturer’s official website, and the aircraft itself performs verification. Specifically, the onboard system checks data integrity — such as bit parity and message structure — to ensure everything is in order before allowing the upload,” she says.
Managing Updates
Software updates are regulated and managed through the standard certification process. Field issues are investigated and addressed through the continuous airworthiness process, the TC representative says, adding, “If resolving these issues requires changes to the software, those updates are implemented and approved following the standard certification process.”
Northcote says that software updates are managed through change control processes, where each patch undergoes assessment, verification, and tracking prior to deployment. “During service, reliability is monitored through occurrence reporting, fleet trend analysis, and continuous airworthiness management processes,” she says.
Aircraft operators cannot simply apply patches on their own but must always receive the original software directly from the manufacturer or authorized supplier, observes Zerbini. “In practice, operators monitor mandatory software updates — these may come in the form of airworthiness directives (AD) or, alternatively, service bulletins (SB) issued by manufacturers or vendors,” she says. “These documents define the minimum software modification standard that must be installed on board the aircraft for compliance. This applies to those systems where operators are allowed to intervene and upload software directly on board.”
When it comes to embedded software, which resides inside certain components, the process is different. In such cases, operators may need to physically remove the component from the aircraft and send it to a maintenance shop, where the software update is performed; this is the case for shop loadable software, says Zerbini. “In practice, monitoring software reliability is not usually done as a standalone activity. Instead, it is assessed as part of monitoring the overall performance of the component in which the software is embedded,” she says. “For example, when aircraft operators track the reliability of an EGPWS, they are monitoring the reliability of the entire unit, not just the software. If a software fault does occur, it is usually detected only indirectly through equipment performance. In those cases where [onboard loadable software] equipment is involved, when there is a problem, the solution is to remove the entire component and send it to the shop, where the software can be reloaded or updated, if necessary. Direct failures traceable solely to the software itself are relatively rare in operational service.”
Currently, there is normally not a specific reliability monitoring system dedicated solely to software among aircraft operators, points out Zerbini. “Such monitoring might become more relevant in the future, as more sophisticated methods for tracking software performance are developed. Currently, however, onboard systems simply alert operators to failures at the equipment level,” she says. “For instance, the crew alerting system might indicate that … transponder 2 is not working, but it does not indicate that the fault lies specifically in the transponder’s internal software. Therefore, operators have only partial visibility into software reliability.”
Identifying Software Failures
Detecting software failures directly poses significant challenges for pilots, unless they have experience with issues involving specific systems, such as the navigation database, according to Zerbini. “For instance, when pilots approach an airport with which they are thoroughly familiar, they may identify discrepancies if the airport chart stored in the navigation database contains incorrect information,” she says. “Similarly, issues can arise with EGPWS when terrain data remains outdated, potentially causing the system to fail in providing appropriate warnings. However, recognising such failures typically requires pilots to possess prior knowledge of the specific terrain or airport characteristics.”
Outside of these particular scenarios, software malfunctions generally do not manifest in ways that are immediately apparent to pilots, Zerbini says. “From a pilot operational perspective, the primary indication is that a system fails to perform as anticipated, without necessarily revealing that the underlying cause stems from software-related issues,” she says.
Although software and hardware failures can manifest similarly — through system alerts, unexpected behaviors, or compromised functionality — the underlying causes and the challenges they present differ significantly, Northcote says. “Software failures are due to errors in the design and are possibly revealed only under rare conditions, not random failures, as for hardware. From an end-user perspective, however, the effects from software-related failures are not different from electronic hardware-related ones,” she says.
In airworthiness certification, software architecture serves a critical role by determining how requirements are distributed across software components, the TC representative says.
“The architecture must be demonstrated as meeting acceptable means of compliance. The responsibilities between aircraft manufacturers, suppliers, and software vendors may vary, depending on several factor,” the representative adds. “Software complexity does not directly influence pilot training requirements and operational procedures. Pilot training focuses on aircraft operation and managing diverse emergency situations and system failures. This emphasises the need for robust design, comprehensive testing, clear alerts, and procedural safeguards to ensure safety, even when software errors are not apparent.”
Software architecture is the backbone of system safety, as it ensures, where needed, that requirements such as redundancy, monitoring, or partitioning are met, Northcote says. “Activities in system development are shared, but the aircraft manufacturers remain responsible for the overall safety of the product. Suppliers of systems and equipment, as well as software providers, are contributing to the demonstration of compliance of the system to the applicable certification basis,” she says.
Improved Usability
Certification requirements are built in a way to ensure that pilots do not need to account for the complexity of the systems and associated software used in the operations, Northcote says. “To illustrate this aspect, system modes and alerts are required to be understandable, and procedures should describe degraded modes,” she says. “Potentially critical software development errors, whether latent or apparent, must be mitigated through robust system architecture, continuous monitoring, reliable fallback mechanisms, and clear, unambiguous flight crew alerting.”
Although the underlying software systems may exhibit considerable technical intricacy, the prevailing trend focuses on enhancing user-friendliness for flight crews, affirms Zerbini. “In practice, this complexity remains concealed from pilots, resulting in greater simplicity in cockpit operations. Consequently, pilots experience no operational disadvantage; rather, procedures are often streamlined and simplified. Modern aircraft frequently incorporate software systems … that actively assist pilots during failure scenarios,” she says. “For instance, in case of an engine fire indication, the software not only delivers the appropriate warning and alert but also automatically displays the corresponding emergency checklist by presenting procedures in a step-by-step format, systematically guiding pilots through the required analytical and corrective actions. Upon completion of each step, the system advises the pilot about the outcome and automatically advances to the next item, effectively eliminating the risk of inadvertently skipping critical procedures.”
This technological approach enhances flight safety while simultaneously reducing pilot workload, according to Zerbini. “Therefore, while software complexity presents substantial challenges for developers and engineers, its operational impact in the cockpit proves entirely beneficial: improved usability, clearer procedural guidance, and significantly reduced potential for human error,” she says.
It is essential to ensure timely updates, particularly for critical systems, according to Zerbini. “This approach does not advocate for indiscriminate updating of all features, including optional components that may not be essential. Instead, it focuses on updating those systems where new software standards directly contribute to enhanced safety,” she says. “For instance, systems such as EGPWS do not necessarily receive updates at fixed intervals. These updates often contain revised terrain or airport data and may reflect changes, including runway limitations, or other modifications that may or may not have an impact on an operator’s schedule. At the aircraft operator level, continuous monitoring of requirements issued through SBs, ADs, and other regulatory materials is, anyway, very important.”
The industry has recognized that software complexity need not translate to operational complexity for pilots. Through thoughtful design and certification requirements, advanced software systems are making cockpits more intuitive, procedures clearer, and operations safer. Emergency checklists that appear automatically, systems that guide pilots step-by-step through critical procedures, and integrated monitoring that prevents human error demonstrate how properly implemented software enhances, rather than complicates, flight safety.
Mario Pierobon, Ph.D., is the owner and scientific director of a safety consulting and training organization.
