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 Maintenance and Troubleshooting Workshop
- Level: Intermediate-to-advanced
- Status: Draft pending technical review
Learning objectives
- Build an IMA diagnostic plan.
- Interpret grouped symptoms.
- Separate application, module and network faults.
- Use CRDC subscriber mapping.
- Verify software/configuration and full restoration.
1. Purpose and operational value
The workshop uses application allocation, signal routing and A/B network evidence to localize shared-resource faults without unnecessary replacement of multiple ATA-system LRUs.
2. Architecture and system flow
Start with the symptom grouping and message sequence: one application, all applications in one CPIOM, mixed remote signals, one network path or several ATA systems.
Map every affected function to its CPIOM partition, CRDC channel and AFDX route.
Preserve configuration, software and first-fault records before reset or module replacement.
3. Major components and functions
Evidence capture
Records ECAM/dispatch/CMS sequence and affected functions. 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 message order, module allocation and network state. Command, feedback and physical effect must agree before hardware is condemned.
Application mapping
Links affected functions to CPIOM 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 hosted-app list, redundancy and dependencies. Command, feedback and physical effect must agree before hardware is condemned.
Signal mapping
Links remote I/O to CRDC channels. 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 subscriber allocation, local wiring and alternate path. Command, feedback and physical effect must agree before hardware is condemned.
Network mapping
Separates A/B, switch, cable, port and end system. 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 NBF, link and virtual-link evidence. Command, feedback and physical effect must agree before hardware is condemned.
Restoration verification
Checks configuration and every affected application. 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 loads, tests, messages and cross-ATA operation. Command, feedback and physical effect must agree before hardware is condemned.
4. Normal operating sequence
1. Preserve
Save messages, allocation and configuration.
2. Classify
Application, module, CRDC or network layer.
3. Compare
Use paired CPIOM, alternate CRDC and A/B paths.
4. Repair
Correct hardware, wiring, software or configuration.
5. Verify
Test all affected users and redundancy.
5. Control, monitoring and protection
Resetting a common module can erase the best evidence and temporarily restore several applications.
Replacing multiple system LRUs before checking shared IMA allocation creates unnecessary work and can hide the root cause.
6. Failure modes and maintenance reasoning
- Several ATA messages: Common CPIOM or network.
- One hosted app: Partition/application/external dependency.
- Mixed local signals: CRDC/channel/power.
- One network path: Switch/cable/end-system A or B.
- Post-replacement mismatch: Software/configuration.
- Intermittent errors: Power, thermal, connector, cable quality or software.
7. Interfaces with other aircraft systems
- ATA 24/31/45.
- Every hosted system.
- Common installation and cooling.
- Configuration management.
- AFDX and CRDC infrastructure.
8. Practical maintenance scenarios
Multiple warnings clear after CPIOM reset
Treat as intermittent common-resource fault.
One analog input wrong, other CRDC path correct
Local sensor/wiring/channel.
A network down, B healthy
Verify degraded redundancy and dispatch.
New module repeats same messages
Investigate power/cooling/configuration/external path.
9. Technician takeaways
- Map before replacing.
- Use common-resource message hierarchy.
- Redundancy is path-specific.
- Verify software, network and hosted applications.
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?
