PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Questions (https://www.pprune.org/questions-67/)
-   -   LNAV v. conventional procedures (https://www.pprune.org/questions/473899-lnav-v-conventional-procedures.html)

RUNAWAY STABILIZER 10th Jan 2012 23:31

LNAV v. conventional procedures
 
Hello guys,

I was wondering if someone is able to help me find a legal paragraph which states how much our LNAV function allows us to not follow conventional procedures i.e. holding patterns entries, racetracks, repositioning...
So far DOC8168 only gave me a foggy idea, which would make me stick to the roots.

Greetz

STBYRUD 12th Jan 2012 10:35

Hey Stab, welcome to the forums first of all! Just to clarify - you are asking what gives us the right to fly (false) LNAV holding entries and to build an LNAV path that looks somewhat like the published racetrack (but is obviously not timing based)? I am wondering too, since I don't have the answer I step down a level of automation when LNAV is not doing what I would have done back then during my IR check... I suppose that is the answer anyway, its alright to fly LNAV as long as it matches the procedure to be flown.
Cheers!

RUNAWAY STABILIZER 12th Jan 2012 11:51

Hi Rud, yes this is basically what I mean and in many more situation. I support your approach and I'd do it the same way, but as this is mostly considered unnecessary I would rather like to see a legal statement backing us up or justifying us to follow LNAV monitoring conventionally that we stay in the limits.

M.82 18th Jan 2012 00:55

Hi guys

In my case, the company were I fly, has a policies were it says that we are not allowed to create any kind of procedure out of the database. So if we don't have a procedure we should fly conventionally.

Its depends on your company.

I don't really know if you were asking this, sory.
:ok:

BOAC 18th Jan 2012 08:24

I cannot offer any ICAO/etc references, but your company Ops Manual will be your 'authority' as it is 'approved' by your regulatory authority who will know the 'rules'.

If I may, a little history 'rewind'?

When I began flying the 737 with DanAir in the late 80', we had aircraft with basic IFR nav equipment and Omega type kit and Doppler. Navigation across beacon-less surfaces was done by calculating drift from observed and forecast winds/Doppler (over water), 'coasting' out on a VOR or NDB radial, then using cross-cuts from Vor/DMEs where available plotted on the chart until eventually either a coastal NDB or VOR would come in range to allow refinement. It worked.

With the 300 737 along came the FMC/INS. Now we used to check position accuracy at intervals, eg before setting off across the GFA or starting descent, and use it if it was OK. Holds etc were flown with it (subject to) BUT backed up and monitored with the holding beacon displayed.

BRNAV arrived. Waypoints were no longer necessarily determined by beacons but by random points. Again, cross-checking accuracy was needed, or if the kit used GPS, monitoring of the RAIM.

As GPS nav spread, so we started to use R and ANP to assess whether the 'kit' was OK. Again, at all times, common-sense (Airmaship?) suggests backing up with a 'traditional' beacon where it can be used.

esreverlluf 18th Jan 2012 13:37

You will find that most regulatory authorities only specify certain tolerances that must not be exceeded. How you make the aeroplane do that is up to you unless your operator has more stringent requirements.

Likewise, you will probably find a statement in your company documentation that LNAV holding pattern entries are permitted despite them perhaps not being quite the same as the AIP requirements.


All times are GMT. The time now is 14:22.


Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.