Airbus A350 Data Loading System: DLCS, SDL & ATA 45 Architecture Explained

01 · System Overview

Overview of the Airbus A350 Data Loading System (ATA 45)

In modern fly-by-wire commercial aircraft, software constitutes the core intelligence of nearly every operational system. On the Airbus A350 XWB, software lifecycle management—encompassing routine navigation database cycles, operational software upgrades mandated by Service Bulletins (SB), and in-field line maintenance reloading—is governed by the Data Loading System, defined within ATA Chapter 45 (Onboard Maintenance System - OMS).

According to the Airbus A350 Technical Training Manual, the data loading system is designed to execute five fundamental functions:

All data loading operations are accessible through the Human Machine Interfaces (HMIs)of the Onboard Maintenance System (OMS). Maintenance personnel interact with the system via theOnboard Maintenance Terminal (OMT), the Onboard Information System (OIS) display on the Control and Display System (CDS), or through the optional Portable Multipurpose Access Terminal (PMAT).

02 · Domain Segmentation

Dual Loading Architecture: DLCS-ACD (ASFC) vs. Simple Data Loader (OSFC)

To maintain strict isolation between safety-critical flight systems and commercial open-world connectivity, the Airbus A350 data loading system is structured into two completely separate software applications hosted across two distinct avionics hardware cabinets:

1. DLCS-ACD (Data Loading and Configuration System - Aircraft Control Domain): Hosted inside the Avionics Server Function Cabinet (ASFC). The DLCS-ACD application executes all data loading, configuration acquisition, and verification functions for the Aircraft Control Domain (ACD). This includes all flight-critical avionics LRUs connected via the aircraft's System Communication Interfaces (SCIs), as well as internal ASFC hosted application software (ASFC loads).
2. SDL (Simple Data Loader): Hosted inside the Open world Server Function Cabinet (OSFC). The SDL application governs data loading functions for open-world equipment, specifically:
   • The OSFC field loadable software (loads);
   • The Wireless Airport Communication System (WACS) field loadable software;
   • The cabin internal wireless system field loadable software.

Both the DLCS-ACD and the SDL manage their own dedicated onboard memory resources, structured identically into two operational areas: the Inbox area and the Repository area.

03 · Avionics Cyber-Security

Smart Diode Module (SDM): Security Box Authentication

Because modern airliners interface with ground repositories over public cellular/Wi-Fi links and accept commercial USB drives in the cockpit, cyber-security and software provenance are paramount. On the A350, all inbound software imports pass through a dedicated security gateway known as the Smart Diode Module (SDM), hosted in the OSFC.

This deterministic filter ensures that no software can be selected for installation on flight-critical computers without prior verification and cryptographic sign-off by the SDM.

04 · Data Distribution

DLCS Subscribers: AFDX, ARINC 429 & Remote Gateway LRUs

The DLCS-ACD in the ASFC is responsible for flashing software into the aircraft system computers via theSystem Communication Interfaces (SCIs). However, because of input/output bandwidth limitations and finite computing resources, the DLCS-ACD cannot interface with every single avionics box directly.

Instead, the A350 establishes three well-defined subscriber categories for data loading:

1. Direct AFDX Network Subscribers

Avionics computers equipped with native AFDX (Avionics Full-Duplex Switched Ethernet)input/output functions connect directly to the DLCS-ACD through virtual links. Key examples include:

• Air Data/Inertial Reference Units (ADIRUs): Such as 1FP1 (ADIRU 1), 1FP2 (ADIRU 2), and 1FP3 (ADIRU 3), receiving operational programs and data tables.
• Flight Management Computers (FMC): FMC-A, FMC-B, and FMC-C (e.g. FIN 1CC3), receiving navigation databases and performance models.
• Core Processing Input/Output Modules (CPIOMs): Integrated Modular Avionics (IMA) processors such as CPIOM-J11 hosting operational core software and configuration tables.
• Common Remote Data Concentrators (CRDCs): Distributed data acquisition nodes managing peripheral sensor inputs.

2. ARINC 429 Module Subscribers

Certain LRUs communicate over classic point-to-point avionics digital buses. For these units, the DLCS-ACD performs data loading through dedicated ARINC 429 input/output module functions:

• Audio Management Units (AMUs): Managing cockpit voice routing, radio communications, and interphone channels.
• Multi-Mode Receivers (MMRs): Precision landing and navigation sensors combining ILS, GLS, and GPS capabilities.

3. AFDX Gateway Subscribers & Remote LRUs

To avoid running heavy individual data loading lines to dozens of remote peripheral units distributed throughout the airframe, certain primary LRUs equipped with an AFDX interface operate asgateways. In this architecture:

• The DLCS-ACD uploads the package directly to the primary AFDX gateway computer over the high-speed network.
• The gateway computer takes custody of the data and relays the transmission downstream to remote components.
• Downstream transmission from the gateway to remote LRUs is conducted using specialized sub-buses, including:ARINC 429, Ethernet, Controller Area Network (CAN) bus, or serial buses.

Prominent examples of this gateway arrangement include:

• Cabin Intercommunication Data System (CIDS) Directors: The CIDS Directors receive cabin software over AFDX and act as gateways to flash Decoder/Encoder Units (DEUs)distributed across the passenger cabin.
• Remote Braking Control Units (RBCUs): Decentralized brake actuation controllers located near the landing gear bays, updated via gateway routing across serial or CAN interfaces.

05 · Memory Resource Management

Onboard Software Database: INBOX vs. REPOSITORY (REF) Partitions

A core design principle of the A350 OMS is the complete onboard availability of operational software. The onboard software database is a dedicated memory resource designed to maintain a local master copy of all field loadable software (loads) operating across the aircraft computers.

The aircraft houses two physical onboard databases:

• ASFC Database: Dedicated to all avionics LRUs and internal ASFC application software.
• OSFC Database: Dedicated to open-world applications, OSFC software, and wireless systems.

Each database is partitioned into two distinct functional zones:

06 · Maintenance Procedures

Software Upload Synoptic: Repair vs. Upgrade Workflows

During aircraft servicing, software uploading is initiated under two distinct scenarios:Software Repair (restoring a known good state from the onboard repository) andSoftware Upgrade (installing a newer version from the inbox).

Scenario A: Software Repair (From Repository)

Software uploading directly from the onboard repository is executed in two specific maintenance circumstances:

1. An unusual software operation: Correcting a transient glitch, operational anomaly, or corrupted memory sector.
2. Removal or installation of a hosting computer: When a replacement LRU is installed on the aircraft and the required operational software was not pre-loaded prior to installation (software missing).

Repair Workflow:

• The mechanic navigates to the appropriate data loading HMI (DLCS-ACD for avionics, SDL for open world).
• The mechanic selects the target computer and specifies the required software stored in the REP (Repository) partition.
• Upon activation of the uploading order, the software from the repository is copied directly into the target computer(s), quickly restoring the validated aircraft configuration.

Scenario B: Software Upgrade (From Inbox)

A software upgrade is performed when introducing a new software revision, such as updating a navigation database or incorporating an Airbus Service Bulletin (SB).

Upgrade Workflow:

1. The mechanic opens the dedicated data loading HMI (DLCS-ACD or SDL).
2. The mechanic performs a check of the INBOX repository:
   • Case 1 (Inbox is complete): If the required software version has already arrived via automatic ground transfer, the mechanic selects the software directly.
   • Case 2 (Inbox is empty or files are missing): The mechanic performs a manual import by inserting a USB device into the OMT front face import port. The SDM authenticates the files and places them into the inbox. The mechanic then selects the software.
3. The mechanic initiates the uploading order. The software in the inbox is copied simultaneously into:
   • The target computer(s) across the SCIs;
   • The related onboard repository (REP) to establish the new onboard baseline.
4. Once the upload and configuration validation succeed, the software is automatically erased from the inbox.

07 · Cockpit Interface

Cockpit Maintenance HMIs: OMT, PMAT & OIS CDS Display Formats

Maintenance operators command and monitor all data loading operations using the cockpit maintenance HMIs. Crucially, the Airbus A350 enforces a strict menu partition on the OMS HMI depending on the system domain:

• DLCS-ACD Menu: Accessed via A/C Management → Software Upload and Configuration Validation. This menu is exclusively used for Aircraft Control Domain software (all avionics LRUs and ASFC software).
• SDL Menu: Accessed via Additional Functions → Open World Upload and Configuration Validation. This menu is exclusively used for OSFC software and cabin/wireless systems.

OMT Display Architecture & Interactive Controls

When working in the UPLOAD & CONF VALIDATION - TARGET SEARCH display on the OMT, the interface provides sophisticated search and filtering tools:

• Search Fields: Technicians can query by ATA Chapter (e.g. ATA 34 or 34-12), FIN (Functional Item Number) (e.g. 1FP1 for ADIRU 1), or Functional Designation (e.g. ADIRU).
• Target List Hierarchy: Displays parent hardware units (e.g. 1FP1 - ADIRU-1) and their subordinate software loads (e.g. 1FP1SW1 - SOFTWARE-ADIRU 1 OPERATIONAL PROGRAM, 1FP1SW2 - SOFTWARE-ADIRU 1 DATA TABLE 1, and 1FP1SW3 - SOFTWARE-ADIRU 1 DATA TABLE 2).
• P/N Selection & Dataloading: Provides toggle selections for = Inbox or = Reference with a contextual Select P/N... dropdown menu.
• Current Configuration Block: Displays real-time parameters from the LRU, including Hardware Part Number (e.g. HG2030BE02), Serial Number (S/N), Amendment (AMDT), and 16-bit Cyclic Redundancy Check (CRC, e.g. 15c4df).
• Validation Action Keys: Dedicated softkeys include Upload P/N, Validate P/N, View Target List, and Confirm Selection.

08 · Configuration Integrity

Configuration Reporting, Cyclical Monitoring & Validation Tiers (N / N-1 / N-2)

Uploading software is only half the process. In civil aviation, maintaining an auditable, verified configuration record is legally mandatory. The DLCS-ACD and SDL incorporate comprehensive configuration reporting engines that execute four distinct tasks:

1. Current Software Configuration Reporting

The configuration reporting application queries, acquires, and persistently stores the hardware and software configurations of all aircraft computers capable of reporting their identification (LRUs). When an upload completes, the target computer transmits its newly installed software identity to the DLCS-ACD or SDL. The system presents this reporting on the OMS HMI with the notificationCONF TO BE VALIDATED, awaiting the technician's physical sign-off.

2. Formal Configuration Validation & Former Version Purge

The maintenance operator verifies the reported part numbers against the engineering authorization or Service Bulletin paperwork and activates the Validate P/N command.

3. Continuous Software Configuration Monitoring

The configuration reporting function continuously monitors the health and identity reported by all LRUs. If any LRU reports an unexpected, corrupted, or incompatible software part number during routine power-ups, an immediate warning is triggered and presented to the maintenance operator on the OMS.

4. Storage and Three-Tier Historical Comparison (N / N-1 / N-2)

The system maintains a historical registry of aircraft software configurations, structured into three validated tiers:

• Current Validated Config (N): The active, officially certified aircraft baseline currently in service.
• Previous Validated Config (N-1): The immediate prior configuration baseline before the last software modification.
• Oldest Validated Config (N-2): The historical baseline two revision cycles prior, preserved for troubleshooting and audit trails.

The system cyclically compares the last refreshed LRU configuration with the validated baseline. If any discrepancy is detected between the actual state and the validated reference, the system automatically proposes a targeted uploading operation to rectify the mismatch.

Mandatory Maintenance Directive: The mechanic is required to verify the current aircraft computer software configuration both before and after every software uploading procedure.

09 · Data Retrieval

Files Downloading & The OSFC Export Box Architecture

In addition to uploading software, the A350 data loading system provides a standardized bidirectional path to retrieve data files from aircraft systems—including maintenance logs, Built-In Test Equipment (BITE) records, Flight Management operational data, and Aircraft Condition Monitoring System (ACMS) recordings.

According to the source manual, this downloading function concerns only the LRUs managed through the DLCS-ACD.

The Export Box Data Flow

1. File Selection on HMI: The technician accesses the DOWNLOAD page on the OMT or CDS. The technician selects the target computer (e.g. FMC-C 1CC3 under ATA 22-77-00) and marks the specific file items (e.g. FILE 1 through FILE 7) for download.
2. Extraction via DLCS-ACD: When the operator selects Download & Export, the DLCS-ACD retrieves the requested files from the target LRUs via the SCIs.
3. Staging in the Export Box: The retrieved files are transferred across the cabinet boundary into the Export Box, a secure memory buffer partition hosted in theOpen world Server Function Cabinet (OSFC).
4. Dual Retrieval Pathways: Once staged in the Export Box, the maintenance files can be extracted through two independent channels:
   • Physical USB Extraction: The mechanic connects a USB flash drive to theDATA EXPORT plug on the front face of the OMT and transfers the files locally.
   • Wireless Ground Offload: The files are routed to the OSFC Communication (COM) Manager, which establishes an IP COM connection over wireless systems (such as WACS) to transmit the files directly to Airline Facilities.

10 · Practical Maintenance

Line Maintenance Engineer's Operational Summary

For line maintenance engineers, avionic technicians, and Part-66 certifying staff working on the A350, mastering the data loading system is critical to aircraft turnaround times. A structured operational mental model can be summarized in three golden rules:

11 · Technical Reference

Frequently Asked Questions (FAQ)