Educational familiarization only. This TechOpsBase resource is an original learning transformation grounded in a privately supplied B737 MAX ATA 22 source. It does not reproduce manufacturer task steps, limits, figures or controlled maintenance instructions. Current approved data and aircraft effectivity control real work.
What this resource teaches
Learn what BITE can tell you—and what it cannot.
BITE organizes fault evidence by channel
The source maps channel A to FCC-A and channel B to FCC-B. Fault review can show suspect LRUs and interface pins, which is useful for narrowing a complex network.
Current status and history answer different questions
Current status describes what the system sees now; history can preserve intermittent events that are no longer active. Treating those as identical can waste troubleshooting time.
Interactive/surface tests add controlled stimulus
BITE can request interactive tests and surface tests for autopilot, flight director, trim and related functions. The educational concept is controlled stimulus plus observed response—not memorizing the test sequence.
A suspect LRU is not a replacement order
The source itself directs the technician to IFIM procedures based on the maintenance message. That is the correct boundary: BITE selects evidence; approved fault isolation determines the action.
Handover value
Record channel, conditions, current/history status and which tests passed/failed. That preserves reasoning for the next technician without copying controlled task content.
Put this topic into the wider system
Redundant channels provide comparison
FCC A/B and their BITE channels give maintenance a way to compare independent processing paths. A channel-specific event is different from a symptom common to both channels, which may point toward shared inputs, power, control authority or downstream interfaces.
Autoflight is a consumer of other systems
Air-data/inertial/navigation information from ATA 34, hydraulic/control authority from flight-control systems and indications through ATA 31 all contribute to the observed autoflight result. A mode problem can therefore originate outside ATA 22.
Deeper system reasoning
BITE history is more useful when tied to the event
Current status, fault history, autotest, interactive tests and surface tests answer different questions. History can preserve what was detected around a past event; a current test may pass after the condition disappears. The chapter specifically exposes maintenance monitors, suspect LRUs and interface information to guide IFIM work. The technician’s job is to correlate that evidence with the reported flight condition, channel, mode and physical response rather than treating “BITE passed” as proof that no intermittent problem existed.
Technician evidence matrix
Record selected/armed/active modes, FCC channel, required sensor/navigation inputs, downstream control authority, physical response and BITE current/history evidence.
Before using a maintenance message as a conclusion, note what independent evidence agrees with it and what evidence does not. If an alternate source, channel or display changes the symptom, record that explicitly because it can separate a common path from a source-specific path. Preserve configuration and event conditions in the handover so the next technician does not have to rebuild the diagnostic context from memory.
Evidence-first study method
For any system complaint, separate source/input, control logic, physical response, sensing/indication and consumer/result. When two layers disagree, that disagreement is useful evidence. Do not turn that evidence into a maintenance action until the applicable approved fault-isolation or maintenance data is open.
Approved-data boundary
Educational system explanation only. Do not use this page to perform maintenance, operate aircraft systems, isolate components or determine dispatch status. Current approved maintenance data, aircraft effectivity and operator procedures control real aircraft work.
