Educational familiarization only. This is original TechOpsBase learning content created from privately supplied legacy training and MSG-3 source material. It does not reproduce manufacturer pages, proprietary diagrams, task steps, numerical maintenance limits, dispatch criteria or controlled maintenance data. Current approved aircraft data, effectivity and operator procedures govern all aircraft work.
Resource profile
- Aircraft: Airbus A350 family
- ATA chapter: 42 — Integrated Modular Avionics
- Resource: A350 ATA 42 IMA Architecture and Shared Resources
- Level: Intermediate-to-advanced
- Status: Draft pending technical review
Learning objectives
- Explain shared-resource philosophy.
- Describe clusters and remote data collection.
- Identify benefits and common-cause risks.
- Trace application-to-I/O flow.
- Use allocation data in troubleshooting.
1. Purpose and operational value
The IMA architecture organizes common computing and communication resources so multiple aircraft-system applications can share standardized modules safely.
2. Architecture and system flow
Conventional LRUs combine input acquisition, computation and outputs for one system; IMA separates and shares these resources.
CPIOMs are grouped in clusters and installed in the avionics compartment, while CRDCs are distributed near remote sensors and actuators.
Standardized interfaces and partitioning reduce wiring and box count while requiring careful common-resource fault analysis.
3. Major components and functions
CPIOM clusters
Group common computing modules. The component must receive the correct input, perform its intended function and provide a valid output or status. A maintenance diagnosis must separate loss of power, loss of communication, incorrect configuration, blockage or leakage, contamination, mechanical degradation and an upstream or downstream interface failure. Useful evidence includes module identity, location, hosted applications and cluster power/network. Command, feedback and physical effect must agree before hardware is condemned.
Shared processing resources
Provide processor, memory and I/O to partitions. The component must receive the correct input, perform its intended function and provide a valid output or status. A maintenance diagnosis must separate loss of power, loss of communication, incorrect configuration, blockage or leakage, contamination, mechanical degradation and an upstream or downstream interface failure. Useful evidence includes resource health, utilization and watchdog events. Command, feedback and physical effect must agree before hardware is condemned.
CRDC population
Extends standardized I/O to remote zones. The component must receive the correct input, perform its intended function and provide a valid output or status. A maintenance diagnosis must separate loss of power, loss of communication, incorrect configuration, blockage or leakage, contamination, mechanical degradation and an upstream or downstream interface failure. Useful evidence includes location, user allocation and redundant signal path. Command, feedback and physical effect must agree before hardware is condemned.
AFDX infrastructure
Interconnects common resources. The component must receive the correct input, perform its intended function and provide a valid output or status. A maintenance diagnosis must separate loss of power, loss of communication, incorrect configuration, blockage or leakage, contamination, mechanical degradation and an upstream or downstream interface failure. Useful evidence includes A/B network path, switches and end systems. Command, feedback and physical effect must agree before hardware is condemned.
Configuration tables
Adapt common modules to aircraft applications. The component must receive the correct input, perform its intended function and provide a valid output or status. A maintenance diagnosis must separate loss of power, loss of communication, incorrect configuration, blockage or leakage, contamination, mechanical degradation and an upstream or downstream interface failure. Useful evidence includes software/configuration version and effectivity. Command, feedback and physical effect must agree before hardware is condemned.
4. Normal operating sequence
1. Initialize
Common modules load configuration and health monitoring.
2. Host
Applications execute in assigned partitions.
3. Acquire/output
CRDC/CPIOM interfaces collect and command aircraft signals.
4. Communicate
AFDX transfers application data.
5. Monitor
IMA health data supports warnings and maintenance.
5. Control, monitoring and protection
Shared architecture reduces hardware but creates common-resource consequences when a module or network element fails.
Application allocation can change by configuration/effectivity.
6. Failure modes and maintenance reasoning
- Cluster-level loss: Power, switch or multiple module/common resource.
- Single CPIOM loss: Hosted applications affected together.
- Remote-zone signal loss: CRDC, local power or harness.
- Misconfiguration: Unexpected application/interface behavior.
- Common alert pattern: FWS consolidation of IMA root cause.
7. Interfaces with other aircraft systems
- Electrical and cooling systems.
- Aircraft application chapters.
- FWS/CMS.
- Data loading/configuration.
- Common-installation wiring.
8. Practical maintenance scenarios
Unrelated system messages share one module allocation
Treat common IMA resource as primary evidence.
Only remote signals in one area fail
Check CRDC/local installation.
Replacement module creates new mismatch
Verify correct configuration tables/software.
9. Technician takeaways
- Allocation is diagnostic data.
- Shared resources create shared consequences.
- Remote and central modules have different roles.
- Effectivity/configuration must be controlled.
Maintenance boundary
This resource explains architecture, operation, indications and system-level troubleshooting. It intentionally excludes removal/installation instructions, wiring-pin checks, maintenance limits, software part numbers, servicing quantities, inspection intervals and release-to-service criteria.
Review prompts
- What is the required system function?
- Which component commands, processes or physically performs it?
- Which power, fluid, pneumatic or data path is required?
- What command proves the function was requested?
- What feedback or physical effect proves correct operation?
- Which adjacent ATA system can create the same symptom?
- What evidence should be preserved before reset, draining, servicing or software action?
- What hygiene, electrical, pressure, network or safety boundary applies?
