16.3 ACARS, Cabin Systems and Information Systems
Key Takeaways
- The former detailed 5.15 description named ACARS, Cabin Systems and Information Systems with associated BITE; this section retains those examples at familiarisation level.
- ACARS is an addressed VHF and/or satellite datalink (HF is a possible additional path) that uplinks and downlinks operational messages, including automatic OOOI (Out, Off, On, In) event reports.
- Typical cabin teaching uses a cabin intercommunication controller (CIDS or equivalent), cabin interphone and passenger address, attendant panels, and often an in-flight entertainment interface.
- Information Systems, as teaching around the former detailed example, covers airborne information servers and networks that host operational data, electronic documentation and EFB-class applications, isolated from flight-control domains.
- ACARS management units, cabin directors/decoders and information servers all report associated BITE to the CMC, CFDS or CMS.
16.3 ACARS, Cabin Systems and Information Systems
Current Appendix I gives only the broad topic 5.15 heading. The pre-12 June 2024 detailed description listed ACARS, Cabin Systems and Information Systems among its typical electronic/digital aircraft systems. Knowledge level 1 is familiarisation with general arrangement and associated BITE. This section stays on those three historical study examples. It uses Airbus Cabin Intercommunication Data System (CIDS) language, in-flight entertainment interfaces, airborne information servers and electronic-flight-bag-class hosts as typical teaching around those former titles. It does not add cockpit voice or flight-data recorders to that former list.
ACARS — addressed datalink
Aircraft Communications Addressing and Reporting System (ACARS) is a datalink that moves short, addressed messages between the aeroplane and an airline or service-provider ground host. It is not a voice radio and it is not a flight-control computer. A typical installation has a Management Unit (MU) or Communications Management Unit (CMU) that formats messages, chooses the radio path, and interfaces with other avionics (flight management, printers, MCDU/CDU pages, engine-monitoring downlinks).
The usual radio paths at familiarisation level are:
- VHF datalink over land and in terminal areas, using VHF communications transceivers in a data mode (plain ACARS on VHF, or ACARS carried over VDL Mode 2 on later fleets).
- Satellite communications (satcom) over oceans and remote regions where VHF ground stations are out of range.
- Some fleets can also use HF datalink as a long-range alternative. Path selection is automatic in a modern CMU: VHF is preferred when a ground station is available; satcom or HF takes over when it is not.
Messages travel in two directions. Downlink is aeroplane to ground. Uplink is ground to aeroplane. Typical downlinks include engine and performance reports, delay or defect codes, free-text crew messages, and the automatic OOOI event reports. Typical uplinks include weather, pre-departure clearances or company clearances as implemented, loadsheet and flight-plan data, and operational messages for the crew.
OOOI is the standard four-event set used by airline operations:
- Out — off blocks (typically doors closed and parking brake released, type-specific discretes).
- Off — airborne (weight off wheels / air-ground).
- On — landed (weight on wheels).
- In — on blocks (typically parking brake set and a door open).
Those four events let the airline track block times without a voice call. They are generated from discretes and air-ground logic, not from a pilot typing four letters. A failed squat-switch or door discrete therefore produces wrong OOOI times even when the VHF radio is healthy — a classic BITE-plus-interface diagnosis rather than an automatic MU swap.
Associated ACARS BITE covers the MU/CMU, the VHF data mode, satcom avionics as fitted, and the interfaces that supply OOOI discretes and printer/MCDU status. Power-up tests the processor and buses; continuous BITE watches link availability and message failures; initiated tests may key a test message on the ground under AMM radio precautions. A "NO COMM" or failed-message status is as often a radio, antenna, satcom log-on or ground-host problem as a dead MU.
Cabin systems — typical CIDS, interphone and IFE teaching
Cabin Systems in 5.15 means the electronic/digital systems that serve the passenger cabin and the cabin crew, not the fly-by-wire computers. Typical Airbus teaching uses the Cabin Intercommunication Data System (CIDS). Other manufacturers use different product names for the same jobs: cabin interphone, passenger address, attendant panels, lighted signs, cabin lighting scenes, temperature request, and often an interface to in-flight entertainment (IFE).
A typical CIDS-class arrangement has:
- Directors (usually dual) that are the cabin controllers. They hold configuration (cabin layout, numbering, options) and run BITE.
- Decoder/encoder units (DEU) distributed through the cabin: passenger-area units for signs, lights, speakers and handsets; attendant-area units for panels and galley interfaces.
- A Forward Attendant Panel (FAP) and additional attendant panels for cabin lighting, temperature request, passenger call, and system status.
- Cabin interphone between attendants and the flight crew, and passenger address (PA) to the cabin loudspeakers. PA audio typically overrides IFE sound so that a safety announcement is heard.
- IFE as a typical related cabin installation: seat-end video, cabin file servers and wireless access as fitted, with an interface so that PA and safety video can take priority. IFE is cabin equipment; it does not compute flight-control laws.
Cabin BITE is heavily used in service because the cabin is full of Line Replaceable Units and passenger-abused handsets. Directors report to the CFDS/CMS or equivalent. A single DEU fault should affect a local zone, not the whole cabin; a dual-director or bus fault can darken signs or lose PA. Replacing a director is a configuration task: the loaded cabin layout must match the aeroplane (Chapter 12 software/data control in miniature). Initiated cabin tests can flash every sign and chime every attendant handset; they are run only when the cabin is safe to test.
[!NOTE] PA and cabin interphone are operational safety tools. A failed PA is not a "passenger convenience" defect in the same sense as a broken IFE screen. Follow the type MEL; do not assume that an IFE reset restores PA.
Information systems — AIS, networks and EFB-class hosts
Information Systems was the former 5.15 title for the airborne systems that store and move operational information rather than flight-control laws. Typical teaching covers:
- An Aircraft Information System (AIS) or onboard information/network server that hosts manuals, performance data, cabin files, software-loading packages as authorised, and airline operational applications.
- An onboard network that may use Ethernet/AFDX-class technology, wireless access points and domain separation. Classroom language often splits an aircraft-control domain, an airline information domain and a passenger domain so that IFE or a passenger device cannot write into flight controls.
- Electronic Flight Bag (EFB)-class information: charts, documentation, performance and MEL-type references presented on installed or portable crew devices. EFB classification details are operational/airworthiness material outside this familiarisation section; the Module 5 point is that EFB-class hosts are information systems, not FBW computers.
Information-system BITE reports server health, network links and interface status to the central maintenance function. Failures typically cost documentation, connectivity or cabin file services, not pitch control. Data loads onto information servers are still controlled loads: an unapproved document set or an unauthorised network change is a configuration issue, not a casual USB copy. Isolation from the flight-control domain is a maintenance-relevant design feature: never "temporarily" bridge a passenger network onto an avionics bus to make a cabin wireless access point work.
| Former detailed 5.15 example | Typical general arrangement | Typical associated BITE / interface |
|---|---|---|
| ACARS | MU or CMU; VHF datalink and/or satcom (HF as fitted); printer/MCDU pages | MU/CMU BITE; radio and satcom path; OOOI discretes |
| Cabin Systems | CIDS-class directors, DEUs, FAP, cabin interphone and PA; IFE interface as fitted | Director/DEU BITE to CFDS/CMS; PA override of IFE audio |
| Information Systems | AIS or network servers; domain-separated onboard network; EFB-class operational data | Server and network BITE; controlled data loads; isolation from FBW |
Associated BITE and what this section does not claim
The former detailed description paired all three examples with associated BITE. The ACARS MU, cabin directors and information servers set power-up, continuous and initiated tests into the same CMC/CFDS/CMS picture taught in section 16.2. A cabin IFE reset that "fixes" a PA complaint has not isolated the CIDS director. An ACARS NO COMM with healthy VHF voice may still be a data-mode, satcom-log-on or OOOI-discrete fault. An information-server disk fault does not explain a Direct-law message on the flight-control page.
Level 1 does not require you to memorise every ACARS label, every CIDS menu or every EFB policy paragraph. For study, know these three examples retained from the former detailed 5.15 description, the VHF/satcom and OOOI picture for ACARS, the CIDS/interphone/IFE picture for cabin systems, the AIS/network/EFB-class picture for information systems, and that associated BITE reports to the central maintenance function.
Which description of ACARS is correct at Module 5.15 familiarisation level?
Which statement correctly describes typical cabin systems named in 5.15?
What does Information Systems mean as a former detailed 5.15 example at familiarisation level?
Which set matches the remaining examples retained from the former detailed Appendix I 5.15 description?
You've completed this section
Continue exploring other exams