8.3 Remote Data Concentrators and Integrated Modular Avionics

8.3 Remote Data Concentrators and Integrated Modular Avionics

Current Module 5.15 is the broad heading Typical electronic/digital aircraft systems at level 1 for every category. Integrated Modular Avionics appeared in the pre-12 June 2024 detailed 5.15 examples; it is retained here as historical study scope, not as a name printed in the current consolidated Appendix I. This section stays at that level: what an IMA cabinet is, how shared processing differs from a federated LRU, where a Core Processing Input/Output Module (CPIOM) fits the teaching picture, why remote data concentrators exist, and how BITE names a cabinet, a module and a hosted function. It is not a software-design course; configuration control and the catastrophic effect of unapproved loads belong with topic 5.13, but the technician still needs to recognise that IMA functions are software-hosted and therefore part-numbered.

Federated LRUs: the architecture IMA replaces

In a federated avionics architecture each major function occupies its own line-replaceable unit. A flight-control computer, a flight-management computer, a flight-warning computer, a display generator and an EGPWS computer are separate boxes. Each box has its own processor, power supply, I/O cards, cooling path, BITE and, typically, its own dedicated sensor wiring. The advantages are isolation and simple mental mapping: the FMS is that tray, the warning computer is this tray. The costs are weight, volume, power, duplicated spare holdings, and a rats-nest of analogue and discrete wires from wing, engine and fuselage into the avionics bay. Classic-generation airliners are still largely federated; many radios, actuators and sensors remain federated even on IMA aeroplanes.

IMA cabinets and shared processing

Integrated Modular Avionics puts several hosted functions onto common computing resources. Hardware is organised as cabinets in the avionics bay containing processing modules, input/output modules, network switches, power supplies and cooling. Software applications — flight warning, display management, some utility-system controllers, and similar hosted functions — run as partitions on those shared processors. Time and space partitioning (the ARINC 653 teaching idea) keeps one hosted function from overwriting another’s memory or stealing its processor time. The cabinet is then a shared computer centre, not a stack of unrelated boxes that happen to share a rack.

Benefits that appear in every familiarisation brief are fewer unique LRUs, lower weight and volume, common spares, and the ability to add or move a function mainly as a software load rather than as a new dedicated computer. The corresponding maintenance shift is that “the warning computer” may no longer be a single tray you can hold; it is a hosted application on a module in a slot, plus the I/O and network that feed it. A module failure can affect several hosted functions at once, which is the opposite of federated isolation. Redundant cabinets and redundant network paths are therefore part of the general arrangement, not an optional extra.

Not every aircraft function is hosted. Radios, some flight-control actuation electronics, and many sensors remain specialised LRUs. IMA is a hosting architecture for a defined set of applications, not a claim that the aeroplane has only one computer.

CPIOM teaching (Airbus-style IMA)

On Airbus A380/A350-class IMA teaching, the Core Processing Input/Output Module is the shared processing and I/O brick. A CPIOM provides computing resource and a set of analogue, discrete and digital interfaces. Several partitioned applications can be hosted on one CPIOM type; identical hardware in different slots can carry different software loads. Input/output modules and remote devices extend the I/O where the cabinet itself should not collect every wire. Modules communicate over the avionics data network (AFDX / ARINC 664 teaching: switched Ethernet with virtual links), not over a private analogue loom for each function.

Boeing 787-class teaching uses different names — Common Core System, common computing resource cabinets, common data network — for the same architectural idea: shared cabinets, hosted functions, and remote concentration of I/O. Do not treat CPIOM as a Boeing part number or CCS as an Airbus part number; treat both as examples of shared IMA processing. Other types (for example the A220) also use IMA cabinets; the examination point is the architecture, not a single fleet.

At level 1 you should be able to say: the cabinet holds shared processors and I/O; hosted software is configuration-controlled; the network carries the data; BITE in the central maintenance function can name the cabinet, the module slot and the hosted application. You are not expected to recite partition budgets or design-assurance levels here.

Remote data concentrators and wiring

A remote data concentrator (RDC, sometimes remote interface unit in local manuals) sits physically near clusters of sensors and effectors — wing, landing gear bay, cabin, engine pylon — rather than in the avionics cabinet. It digitises analogue voltages, reads discretes, drives some analogue or discrete outputs, and forwards the results as digital messages on the aircraft network. The long run through the pressure bulkhead is then a data-bus or network cable instead of dozens of dedicated copper pairs for every thermocouple, proximity switch and position sensor.

That is the wiring-reduction argument. On a large aeroplane, federated analogue looms are a major mass item and a major source of connectors, shielding and troubleshooting time. Concentrating I/O locally also shortens analogue leads, which improves noise immunity — a practical link to topic 5.14 — and lets the IMA cabinet see a clean digital dataset. The RDC itself is a line-replaceable item with its own BITE: failed channels, power, and network links are reported, so a single missing parameter may be an RDC channel rather than a CPIOM or a sensor.

RDCs are supporting architecture for IMA; they are not a 1960s-only analogue multiplex box, and they are not a circuit-breaker panel. Older aircraft did use analogue multiplexers (section 8.2) inside a federated LRU. An RDC on an IMA aeroplane is a networked I/O node. Confusing the two is the usual examination mix-up: a 4051 on a card scans sensors for one computer; an RDC serves many hosted functions through the cabinet network.

General arrangement and associated BITE

Level-1 general arrangement, in cockpit and bay terms, is: IMA cabinets in the avionics compartment, often dual or more for dispatch; processing and I/O modules in numbered slots; network switches; power and cooling; RDCs out in the airframe; remaining federated LRUs still on the data network. Crew interfaces (ECAM/EICAS, FMS, displays) may be hosted or may remain separate display units fed by hosted display-management applications — fleet-specific, but always digital-bus-fed rather than a unique analogue loom per instrument.

Associated BITE is reported through the central maintenance computer / centralised fault display (the aircraft’s CMS/CFDS teaching names). Typical messages identify an IMA cabinet, a module type and slot, a hosted function name, and/or an RDC and channel. Trouble-shooting therefore starts with the message topology, not with “swap the warning computer” as if it were still a unique tray. Power, cooling and network links are first-look items because they are shared. Software part numbers and aircraft configuration lists must match the hosted load; an unapproved or mismatched load is an airworthiness event, not a harmless experiment, which is why IMA and topic 5.13 meet at the data-loader.

The MSI blocks from sections 8.1 and 8.2 still exist inside these VLSI modules — encoders, decoders and multiplexers remain the way a module scans discretes and analogue channels — but the line technician meets them as BITE on an RDC or I/O module, not as a 74151 you replace on the bench during a turnaround. That is the scale jump from 5.8/5.9 at B2 level 2 to 5.15 IMA at level 1 for all categories.