EFB Software Types Explained: A, B, and C Apps

EFB SERIES · PART 3 OF 8 — Technology, Security & Safety · Series Hub · ← Part 2 · Part 4 → (publishes Sep 7)

TL;DR — What are EFB software types? EFB software is classified by the worst-case effect of its failure or misuse: Type A has no safety effect (document viewers), Type B has a minor effect the crew can detect and mitigate (moving maps, performance and weight-and-balance calculators, electronic checklists), and Type C has major-or-worse effects and therefore requires full DO-178C design assurance like certified avionics. Type B is the workhorse category of the modern flight deck.

Part 2 ended on a boundary: the certified airplane on one side, the portable EFB world on the other, an AID standing between. Software classification is that same boundary expressed in code. Nobody certifies an EFB app the way a flight-control computer is certified — and yet crews make operational decisions with these apps every day. The regulatory answer to that tension is a deceptively simple question asked of every application:

What is the worst thing that happens if this software fails, or is used wrongly?

The answer sorts every piece of EFB software into one of three types — and through those types, everything else follows: who approves it, what it may replace on paper, how it must be built, and how deeply Part 6’s attackers care about it.

How Regulators Classify EFB Software

Software type is determined by failure effect, and failure effect maps onto the design-assurance ladder that avionics engineers have used for decades.

Table T3.1 — The three software types

The DO-178C ladder underneath

The avionics world quantifies “how bad is a failure” with Design Assurance Levels under RTCA DO-178C / EUROCAE ED-12C — DAL A (catastrophic) down to DAL E (no effect). EFB types sit broadly at the relaxed end of that ladder:

Table T3.2 — DAL ↔ EFB type broad equivalence (synthesis; exact framing varies by authority and revision [verify against current AC/AMC text])

The nuance worth internalizing: a portable Type B application is usually not held to full DO-178C DAL D paperwork. Instead, regulators accept a safety argument by procedure: the tool’s output is advisory, cross-checkable, and the crew has the means and time to detect a wrong answer. That argument is exactly why the operational program around the app (training, cross-checks, redundancy — Parts 5 and 8) is inseparable from the software itself. Take away the procedural containment and Type B’s safety case collapses.

The Type B Ecosystem, App by App

Type B applications form the working cockpit: seven families of advisory software that replaced the paper bag’s contents and then grew capabilities paper never had.

Table T3.3 — The Type B inventory

Electronic charts and the geo-referenced moving map

The flagship Type B application displays terminal and enroute charts, and — the feature that sold the entire EFB era — draws own-ship position on the approach plate.

Mechanically, geo-referencing is a coordinate marriage. Each digital plate is calibrated: the chart publisher ties identifiable plate features to WGS-84 coordinates, so every pixel of the plate maps to a real-world position. The aircraft’s position comes from one of two sources — the tablet’s internal GNSS receiver, or (better, on Class 2-style installs) the AID-fed blended position from the aircraft’s FMS/IRS, which is the same data the certified systems use. Render = calibrated plate + position + heading, updated continuously. The engineering wrinkle is latency: position arrives with delay, smoothing algorithms average, and at taxi speed the symbol trails the airplane. Symbology standards and crew training both exist to stop anyone flying the symbol rather than the aircraft.

Takeoff and landing performance calculators

The perf app is the highest-consequence Type B family. It encodes the aircraft’s AFM performance model and, given runway, weather and configuration, computes V-speeds, thrust settings (including flex/derated thrust), and runway-limited weights. Its error profile inverts paper’s: hand-interpolation errors mostly vanish; entry errors (wrong runway, wrong flap setting, wrong weight) become the dominant failure — a wrong-but-plausible answer that no arithmetic check will catch. This is why the app is Type B and not a toy: the safety case leans entirely on independent verification, standard calls, and the crew’s cross-check discipline (Part 8’s human-factors section returns to this exact failure mode).

Weight & balance

The W&B application computes moments and center-of-gravity against the certified envelope, visualizing the load point graphically. Its distinctive risk window is the last-minute change (LMC) — the quick weight adjustment after doors are nearly closed — historically a fertile source of small errors with occasionally large consequences. Graphical envelope display makes the final position obvious in a way columns of numbers never were.

Electronic checklists

Replacing the paper checklist introduces conditional logic: a flow that adapts — items auto-satisfied from aircraft state (via the AID feed where available), abnormal procedures branching by failure. The risk trade is subtle: paper’s linear rigidity (hard to skip silently) is exchanged for software’s adaptability (easier to reset, easier to click through). Type B treatment and checklist discipline procedures acknowledge that trade explicitly.

Document management, weather, and the admin layer

The remaining families behave more like Type A infrastructure with Type B touches: the document library with enforced revision status (an out-of-date manual that refuses to masquerade as current); the weather and NOTAM briefing package (Part 4 covers the data chain that feeds it); and the admin/routing modules — flight release acceptance, tech-log defect entries, electronic signatures — that turned the EFB into the crew’s interface to the operator’s ground IT.

Platform Architecture: How an EFB App Stack Is Built

Commercial EFB platforms are layered systems with services shared across applications — and where mixed-criticality software coexists, partitioning is the safety mechanism.

From the metal up:

1. Hardware layer — the tablet or installed display (Part 2).
2. Operating system — iOS/iPadOS or Android derivatives on portables; on installed platforms, real-time operating systems where multiple applications of different criticality share one box. There, ARINC 653-style time-and-space partitioning (the IMA model, implemented by separation kernels of the INTEGRITY-178 or PikeOS class) ensures a lower-criticality application cannot starve or corrupt a higher-criticality one. The partition wall is the certification argument for mixing.
3. Platform services — the EFB vendor’s middleware: data synchronization (Part 4), position feed, digital-rights management for chart subscriptions, document revision enforcement, logging. This layer is shared by every application — which makes it both a reliability dependency and, as Part 6 will show, a high-value attack target.
4. Applications — the Type A/B families above, distributed as signed enterprise applications through app-store or MDM channels (Part 7’s Layer 1).

The architectural takeaway for the security-minded reader: a Type B label on an application tells you about its failure effect — it says nothing about the platform services underneath it, which inherit trust from the whole stack. Supply-chain compromise of the platform layer poisons every app above it at once. Hold that thought until Part 6.

Type B vs Type C: The Boundary Cases

The line between advisory and certified is drawn where the crew’s ability to detect and mitigate a failure ends.

Consider the gradient. A moving map that merely displays position: Type B — if it’s wrong, the crew cross-checks raw data and approach guidance. A performance tool whose output the crew independently verifies against tables or a second computation: Type B. But software whose output is acted on without independent verification — a certified performance system whose numbers feed directly into thrust setting, a display integrated with aircraft sensors such that its corruption misleads rather than annoys — crosses into Type C: full DO-178C design assurance, certification-authority oversight, and treatment as avionics.

The boundary occasionally surprises people in both directions. A humble-looking calculator can demand Type C treatment if operational procedures stop providing the cross-check that contained its failure. Conversely, sophisticated-looking display apps remain Type B as long as the advisory framing holds. The type follows the safety case, not the feature list — which is why Part 5’s approval process examines procedures and training as seriously as it examines software.

Key Takeaways

• EFB software types are assigned by worst-case failure effect: Type A (none), Type B (minor, detectable, mitigable), Type C (major or worse).
• Type B’s safety case is procedural: advisory output plus crew cross-checks — remove the cross-checks and the classification collapses.
• The DO-178C DAL ladder underneath: roughly DAL E ≈ Type A, DAL D ≈ Type B, ≥DAL C ≈ Type C.
• Seven Type B families run the modern cockpit: charts/moving map, performance, W&B, checklists, documents, weather/briefing, admin.
• Geo-referencing = calibrated plates (WGS-84) + position (internal GNSS or AID-fed blended position) + rendering, with real latency caveats.
• Performance apps changed the error profile: interpolation errors out, entry errors in.
• Platform services are the hidden shared dependency under every app — a single supply-chain trust object (Part 6).

FAQ

What is a Type B EFB application?
An EFB application whose failure or misuse has at most a minor safety effect that the crew can detect and mitigate — e.g., geo-referenced moving maps, performance calculators, weight-and-balance, and electronic checklists. Its safety case rests on advisory use plus procedural cross-checks.

Is ForeFlight Type A or Type B?
Applications like ForeFlight contain both: document viewing is Type A-style functionality, while geo-referenced moving maps and performance features fall under Type B treatment. The classification applies to functions, and the operator’s authorization determines which functions are approved for operational use.

Do EFB apps need DO-178C certification?
Type C software does — full DO-178C design assurance as part of aircraft/product certification. Type A and Type B software generally does not; regulators accept operational risk assessment and procedural containment instead, mapped roughly onto the DAL E/D end of the ladder.

What software can legally replace paper charts?
Approved Type B applications can replace paper charts, approach plates, manuals and performance data, provided the operator’s EFB authorization covers them and documented backup/reversion procedures exist — dual independent devices or retained paper quick-reference items.

What’s the difference between Type B and Type C EFB software?
The boundary is the crew’s ability to contain a failure: Type B outputs are advisory and independently cross-checkable; Type C outputs are relied upon without such verification, so Type C requires full DO-178C design assurance and certification-authority oversight.

How does a moving map know the aircraft’s position?
Either from the tablet’s internal GNSS receiver or — on interfaced installs — from the AID’s filtered feed of the aircraft’s FMS/IRS blended position, the same source the certified systems use. The plate itself is calibrated to WGS-84 coordinates so position can be drawn in the chart’s own frame.

Can an EFB performance calculator be wrong?
Yes — most plausibly through entry errors (wrong runway, configuration, or weight) rather than arithmetic. A perf app’s wrong answers look plausible; that is precisely why Type B procedures demand independent verification and cross-check discipline.

References

1. FAA, Advisory Circular 120-76E — software type definitions and evaluation guidance
2. EASA, AMC 20-25 — Type A/B acceptance framework
3. RTCA, DO-178C / EUROCAE ED-12C — Software Considerations in Airborne Systems and Equipment Certification
4. RTCA, DO-330/331/332/333 — DO-178C supplements (tool qualification, model-based, object-oriented, formal methods)
5. AEEC, ARINC 653 — Avionics Application Software Standard Interface (partitioned RTOS/IMA model)
6. Transport Canada, AC 700-020 — Type A/B failure-effect framing
7. SKYbrary, “Electronic Flight Bag (EFB)”

[← Part 2: EFB Hardware] · [Series Hub] · Part 4: How EFB Data Reaches the Cockpit → (publishes Sep 7)

Parts publish daily through September 11 — bookmark the series hub for the full run.

Current as of September 2026 · standards verified against the latest revisions.
Educational reference only — always follow your operator’s approved EFB program and your NAA’s current guidance.
Author: hmmnm.com editorial team · hmmnm.com

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy