Educational familiarization only. This original TechOpsBase lesson paraphrases system architecture and maintenance reasoning from privately supplied legacy training material. It does not reproduce manufacturer pages, proprietary diagrams, maintenance procedures, task steps, numerical limits, dispatch criteria or controlled data. Actual aircraft work requires current approved maintenance data, correct effectivity, operator procedures, authorization and all required safety controls.
Resource profile
- Aircraft: Airbus A350 family
- ATA chapter: 46 - Information Systems
- Resource: A350 ATA 46 Information Systems - Complete Overview
- Audience: Enthusiasts, students, junior technicians and professionals
- Level: Intermediate-to-advanced
- Status: Draft pending technical review
Learning objectives
- Map the information domains.
- Explain ASFC/OSFC/SCI relationships.
- Identify users and access points.
- Trace secure data flow.
- Apply layered troubleshooting.
1. Purpose and operational value
The information system replaces many paper and standalone workflows with hosted applications, electronic documentation, controlled data exchange and crew-maintenance access.
2. Architecture and system flow
Aircraft-controlled and airline/open-world applications are separated so useful data can move without exposing protected avionics functions.
Server cabinets provide processing, storage, networking and video resources, while terminals and wireless links expose services to authorized users.
The fault pattern—one application, one terminal, one domain or every service—is central to diagnosis.
3. Major equipment and functions
ASFC
Hosts protected aircraft-controlled applications. The item must receive the correct input, execute its function and provide a valid output or status. A fault can be caused by power, communication, configuration, contamination, mechanical condition or an external interface. Useful evidence includes cabinet power, application status, SCI links and video resources. Compare command, feedback and physical effect before replacing hardware.
OSFC
Hosts airline, cabin and open-world applications. The item must receive the correct input, execute its function and provide a valid output or status. A fault can be caused by power, communication, configuration, contamination, mechanical condition or an external interface. Useful evidence includes partition state, network routes, storage and ground-link status. Compare command, feedback and physical effect before replacing hardware.
SCI
Provides firewall/gateway control between domains. The item must receive the correct input, execute its function and provide a valid output or status. A fault can be caused by power, communication, configuration, contamination, mechanical condition or an external interface. Useful evidence includes link state, filtering events and data direction. Compare command, feedback and physical effect before replacing hardware.
EFB/OMT/HMI
Gives users access to hosted services. The item must receive the correct input, execute its function and provide a valid output or status. A fault can be caused by power, communication, configuration, contamination, mechanical condition or an external interface. Useful evidence includes terminal power, session, video/control allocation. Compare command, feedback and physical effect before replacing hardware.
Communication services
Connect aircraft, cabin and ground workflows. The item must receive the correct input, execute its function and provide a valid output or status. A fault can be caused by power, communication, configuration, contamination, mechanical condition or an external interface. Useful evidence includes routing, acknowledgements and security policy. Compare command, feedback and physical effect before replacing hardware.
4. Normal operating sequence
1. Power-up
Cabinets initialize hardware, networks and hosted partitions.
2. User access
A terminal requests a session and receives the correct domain/application.
3. Data exchange
Information passes through routing and security controls.
4. Maintenance
Authorized users access logs, tests, loading and documentation.
5. Control, monitoring and protection
A visible HMI fault does not automatically identify the failed cabinet.
A blocked data path can be correct security behavior rather than a hardware defect.
6. Failure modes and maintenance reasoning
- One application unavailable: Hosted application, partition, database or configuration.
- One domain lost: Cabinet resource, power or network.
- Terminal blank: Terminal, video resource or allocation.
- Transfer blocked: SCI, policy, switch or routing.
- Repeated reset: Underlying hardware, software, thermal or power problem.
7. Interfaces with other systems
- ATA 24 power.
- ATA 45 OMS/CMS.
- ATA 23/46 communication.
- ATA 44 cabin systems.
- Ground airline and cybersecurity systems.
8. Practical maintenance scenarios
Only the OMT is blank
Check OMT power and video/control path before cabinet replacement.
ASFC apps work, OSFC apps do not
Focus on OSFC/AISD resources.
Ground synchronization fails
Separate aircraft app, radio route and ground server.
9. Technician takeaways
- Troubleshoot by layer.
- Preserve logs before reset.
- Security state is evidence.
- A reboot is not root-cause proof.
Maintenance boundary
This lesson is for system understanding and troubleshooting logic. It excludes removal/installation steps, wiring pin checks, software part numbers, test limits, servicing values, maintenance intervals and release-to-service criteria. Use current approved AMM, TSM, WDM, FIM, IPC and operator procedures.
Review prompts
- What function should the subsystem provide?
- Which equipment hosts, controls or distributes it?
- Which power, air, data, audio or physical path carries it?
- What command proves the function was requested?
- What feedback or physical response proves correct operation?
- Which other ATA system can create the same symptom?
- What evidence must be preserved before reset or reconfiguration?
- What safety, security, fire, fuel or emergency boundary applies?
