Area Navigation Systems (RNAV) — Page 270, Lesson 263

We're starting a new topic now: Area Navigation Systems, or RNAV. I want to walk you through what a full 4D RNAV system is required to do, because this list is essentially the certification standard — the minimum capability a system must have to be called a 4D RNAV system. First, let's be precise about what "4D" means here. We're talking about the three spatial dimensions — latitude, longitude, and altitude — plus time as the fourth dimension. So a 4D RNAV system isn't just navigating in space; it's also managing time, which is why you'll see time-to-waypoint requirements in this list. Let me go through these requirements in the order they appear, because each one builds on the last. The first requirement is that the system must display present position. It can show this either as latitude and longitude, or as a distance and bearing to a selected waypoint. So the pilot always knows exactly where the aircraft is, in absolute terms or relative to where they're going. Second, the crew must be able to select or enter the required flight plan through the control and display unit — that's the CDU. The CDU is your interface with the system; it's how you tell the computer what you want to fly. Third, you need to be able to review and modify navigation data for any part of a flight plan at any stage of flight. And critically, the system must store sufficient data to carry out the active flight plan. So you can look at any leg, change it, and the system holds all that information for the route you're actually flying. Fourth, you must be able to review, assemble, modify, or verify a flight plan in flight — but here's the key qualifier — without affecting the guidance output. That means you can work on a plan while the aircraft is still flying the current one, and the autopilot or flight director doesn't get disturbed by what you're doing. Fifth, and this is a safety-critical point: you execute a modified flight plan only after positive action by the flight crew. The system can't just switch to a new route on its own. The pilot has to deliberately confirm and activate it. Sixth, where the system provides it, you can assemble and verify an alternative flight plan without affecting the active one. So you can build a backup route while the current plan stays untouched. Now, the seventh requirement is about how you build a flight plan. You can assemble it in several ways: by identifier — that's the waypoint's name or code; by selecting individual waypoints from the database; by creating waypoints from the database; or by creating waypoints defined by latitude and longitude, or by bearing and distance parameters, or other parameters. So the system has to be flexible in how you define your route. Eighth, you must be able to assemble flight plans by joining routes or route segments. That means you can take an existing airway or a published route and stitch it together with others. Ninth, the system must allow verification or adjustment of displayed position. The pilot needs to be able to check that the position shown is correct and correct it if needed. Tenth, here's a big one: automatic sequencing through waypoints with turn anticipation. As you pass each waypoint, the system automatically advances to the next one, and it starts the turn before you actually reach the waypoint so you don't overshoot. But it also says manual sequencing should be provided, to allow flight over, and return to, waypoints. So the pilot can override the automation and fly directly over a waypoint, or go back to one they've already passed. Eleventh, the system must display cross-track error on the CDU. Cross-track error is how far left or right you are from your intended track — the lateral deviation. You need to see that number. Twelfth, it must provide time to waypoints on the CDU. That's the fourth dimension — the system predicts when you'll arrive at each waypoint. Thirteenth, you must be able to execute a direct clearance to any waypoint. If ATC says "direct to a fix," you can select it and the system flies straight there. Fourteenth, the system must be able to fly parallel tracks at a selected offset distance, and that offset mode must be clearly indicated. So you can fly a track parallel to your planned route — useful for holding patterns or avoiding weather — and the display has to make it obvious you're in offset mode. Fifteenth, you need to be able to purge previous radio updates. That means clearing out old navaid corrections so they don't keep influencing your position. Sixteenth, the system must carry out RNAV holding procedures when they're defined. So it can fly a published holding pattern automatically. Seventeenth, the system must make available to the flight crew estimates of positional uncertainty. This can be shown either as a quality factor — a number indicating how confident the system is — or by reference to sensor differences from the computed position. In other words, if the GPS and the VOR/DME disagree, the system tells you how much they differ. Eighteenth, the system must conform to the WGS-84 geodetic reference system. WGS-84 is the standard coordinate system used worldwide for GPS and modern navigation — it defines the shape of the Earth and the reference frame for all positions. So every waypoint and every position must be in that same frame, or nothing lines up. And finally, nineteenth, the system must indicate navigation equipment failure. If something breaks, you get a clear warning. Let me pull this together. What this list really describes is a system that's fully in control of the navigation task — it knows where it is, it knows where it's going, it can be reprogrammed safely without disrupting the current flight, it handles the timing, it handles the turns, it can fly offsets and holds, and it tells you when it's not sure of itself or when it's failed. That's the complete 4D RNAV capability. One thing I want to emphasize, because it's a theme running through this whole list: the distinction between the active flight plan and everything else. You can build, modify, and verify other plans — but nothing changes the guidance output until the crew takes positive action to execute it. That's a fundamental safety principle in RNAV design. Now, let me show you what this looks like in practice. Here's a figure showing an aircraft flying from waypoint 1, defined by a VOR/DME, to a second waypoint — this illustrates how the system uses ground-based navaids to define and navigate between waypoints. And here's a schematic of the FMS — the Flight Management System — which is the computer that ties all these functions together. This shows how the different components connect. So when you're flying a 4D RNAV system, this is the full capability you're working with. Every one of these requirements is something you'll see reflected in the cockpit — on the CDU, in the flight plan, and in how the aircraft behaves.