V1 is or is not a LOCATION on the runway...

[BoeingBobby]

No, he didn't

TOD vs TODA
TOR vs TORA
ASD vs ASDA

It's the basics of take-off performance claculation.

TOD menas Top Of Descent too.

Funny, I have NEVER heard of most of these. What do you do just make this shit up? Or is it like the new texting stuff like LOL, OMG, ROTFLMAO, YHGTBFSM?

[3WE]

It could be that there's some slop factor that makes this 4-page discussion a ridiculously moot point.

I would also summarize that of the bazillion takeoffs that have succesfully occurred using V1 as a go-no-go decision point throughout aviation history, Gabriel listed ~10 instances where it didn't go so good.

We do need to conceed that that's a pretty good record.

[3WE]

BB, you're not getting the idea....

...As for your rigid interpretation of v1... You can say its v1 all you like, and operationally we treat it that way. But it's of no value whatsoever if you aren't meeting the performance it is predicated on.

MCM, sir...your comment nails it...

...along with the admission that there's at least some possibility that there could be a performance variation that the pilots might not detect.

Now, given that thousands of planes take flight every day using this flawed V1 procedure- maybe it's not too bad (subtle sarcasm)- is there anything the parlour talkers need to hear about- a safety buffer? The thought that there's a high probability that a pilot would detect a performance problem? Or is Boeing Bobby right- it ain't broke so STFU and don't 'fix' it?

Finally, while I like Gabiels mega-accurate-computer-generated-performance-problem-annunciator-light- unfortunately, it is probably going to give bad data or a distraction some day and ...cause a crash...

[MCM]

Funny, I have NEVER heard of most of these. What do you do just make this shit up? Or is it like the new texting stuff like LOL, OMG, ROTFLMAO, YHGTBFSM?

BoeingBobby - now you are, perhaps, showing your age, and perhaps a lack of interest in keeping up with other areas of aviation other than simply sitting in the LHS. Or a desire to stir people up. All of those acronyms are extremely common, and in daily use. TODA, TORA and ASDA appear in NOTAMS here regularly (depending on the route used, once every couple of months). The basic airline transport theory course requires calculations using all of these acronyms, along with the ability to define them both in terms of words and concepts. I had training and testing on these concepts within the first week of my 747 endorsement.

Recently my airline had a slight change to the method used for takeoff calculation, and all of these acronyms appeared in the document explaining the new system and methodology to pilots. I believe you would be in the vast minority of pilots if you genuinely didn't understand the relationship between all of these acronyms.

Now, given that thousands of planes take flight every day using this flawed V1 procedure- maybe it's not too bad (subtle sarcasm)- is there anything the parlour talkers need to hear about- a safety buffer? The thought that there's a high probability that a pilot would detect a performance problem.

I'd disagree that the V1 system is flawed at all. It works perfectly well. There are safety buffers in the system (albeit not particularly large ones in the stop case). But those buffers are there for minor changes in conditions, not 100 tonne changes in weight. I wouldn't worry too much about the system in that regard.

A gross error check for major acceleration errors is probably not a bad idea, and I'm sure the technical boffins could make something that detected major errors. Minor errors are trapped by the buffers. We don't need a system that will tell you at 60kts if you're going to be 50m too far down the runway at V1. We need a system that will tell us if you're going to be 500m too far down the runway...

Finally, while I like Gabiels mega-accurate-computer-generated-performance-problem-annunciator-light- unfortunately, it is probably going to give bad data or a distraction some day and ...cause a crash...

I like the idea of an automated warning that checks takeoff acceleration at say 60 kts and has a takeoff configuration warning style alarm. Yes sometimes they cause crashes (Helios anyone?), but if they save more lives than they take, they're worth it.

[Gabriel]

Funny, I have NEVER heard of most of these. What do you do just make this shit up? Or is it like the new texting stuff like LOL, OMG, ROTFLMAO, YHGTBFSM?

You mean you never looked at an airport directory?

http://www.airnav.com/airport/KORD

I didn't include the LD vs LDA because we were talking about take-off, not landing.

[Gabriel]

Now, given that thousands of planes take flight every day using this flawed V1 procedure- maybe it's not too bad (subtle sarcasm)- is there anything the parlour talkers need to hear about- a safety buffer? The thought that there's a high probability that a pilot would detect a performance problem? Or is Boeing Bobby right- it ain't broke so STFU and don't 'fix' it?

The main reason for the "good luck" is that in most cases there is not an engine failure close to V1, even among the cases where there is an engine failure. And, in many cases, the runway is longer than the minimum needed anyway so V1 is not the speed where you'll tun off the end runway if you abort after it or where you'll not take-off by the end of the runway if en engine fails a bit earlier and you don't abort.

And yes, there is not a lot but some margin. For the ASD it's 2 seconds at V1 plus the use of reversers which are not taken into account for the computed performance.
For the TOR, I honestly don't remember if there is any margin (I guess there is one).
And for the TOD, it's that it's computed for the point where you reach V2 and 35ft but the plane will not suddenly explode if you cross that point with V2-5 and 25ft.

That said, the investigation of this accidnet identified dozens of other similar accidents and incidents where the plane sub-performed and the safety was compromised, including fatal ones.

[Evan]

Um no, I am not suggesting any new call out / procedure at all whatsoever.

Wait a sec... you wrote:

Anyway, what I recall was that the conclusion of this discussion was a pretty compelling dataset and argument that V1 is the way to make that call and not some 'mark' on the runway. (In fact, this would be both a location AND a speed milestone)

So, what use is a marker (a location) that represents a speed milestone if there is no speed callout or procedure related to it?

We have V1 and it works fine if there is no gross error in calculating it. We don't currently have a way to detect such a gross error during the take-off roll. Isn't that what you wanted to discuss?

[3WE]

Wait a sec... you wrote:

So, what use is a marker (a location) that represents a speed milestone if there is no speed callout or procedure related to it?

We have V1 and it works fine if there is no gross error in calculating it. We don't currently have a way to detect such a gross error during the take-off roll. Isn't that what you wanted to discuss?

Discuss yes, suggest that procedures be changed, No.

Your confusion is word parsing:

"Compelling data exist that the current V1 procedure is the way to make the go-no go call and not some mark on the runway"

In other words, no need to change the current procedure.

I added the second part of the sentence to elaborate that you would need more than JUST a mark on the runway- a true acceleration check would require a mark and a speed.

But to repeat- while I can see a technical advantage to a location/speed check (or the electronic equivalent), I do not see a meaningful safety improvement- so discuss, yes...propose change, no.

[Gabriel]

I agree with Evan this time.
The data is there. The technology is there. It takes some command-lines typing. The procedure could be very simple: just add one additional criteria to the take-off config warning.

The ATSB identified 31 occurrences (accidents or incidents) due to wrong take-off computation or data entry alone in the last 30 years (not including other possible cases of poor take-off performance), and those identified are only those that were severe enough to make it into a report. As we see below, at least in one case the crew didn't note anything wrong and was advised of the tail strike by the tower. The list include only those that were similar to the Emirates case (wrong TOW).

Are we going to wait to the next fatal accident (that, instead of a cargo 747 in the list, can be an A380 loaded with 500 souls) to implement it?

The aircraft struck the instrument landing system equipment, the landing gear collapsed and all four engines were torn away.

During the takeoff, the tailskid pan came into contact with the runway, the aircraft failed to become airborne and the captain rejected the takeoff.

Due to over rotation the aircraft sustained a tailstrike.

During the takeoff, the captain sensed that the aircraft was nose heavy. In response, rotation was delayed by 15 kts. After becoming airborne, the captain felt the aircraft was sluggish and requested more thrust. The crew were notified by ATC that the aircraft had sustained a tailstrike.

During the takeoff, the aircraft sustained a tailstrike.

During the takeoff, the aircraft did not respond during rotation and sustained a tailstrike.

The aircraft sustained a tailstrike on rotation.

During takeoff the rear fuselage came in contact with the runway momentarily and then again with greater force. Despite becoming airborne past the end of the runway, the aircraft struck an earth embankment supporting the instrument landing system antenna, and then the terrain, resulting in the aircraft being destroyed by impact forces and a subsequent fire. All seven of the crew members received fatal injuries.

During the takeoff, the aircraft did not lift off as expected, the fuselage contacted the runway and take-off/go-around (TO/GA) thrust was applied by the first officer at the same time the aircraft became airborne.

The crew did not detect the aircraft’s acceleration was lower than normal; however at the V1 speed they noted a reasonable amount of runway remaining and they began to doubt the V speeds, resulting in the captain delaying rotation. When rotation was initiated by the first officer, he felt the aircraft was heavy and pitched up slowly, followed by activation of the aircraft’s stick shaker. He reduced the pitch up command and applied full thrust.

During takeoff, the aircraft appeared to accelerate as normal, however the aircraft did not ‘feel right’ at rotation, so the captain applied TO/GA thrust and the aircraft became airborne and climbed away.

During takeoff, the captain noted the aircraft had sluggish acceleration and delayed the V1 call. Upon rotation the tailskid message illuminated, indicated the aircraft had sustained a tailstrike.

[AA 1818]

Here's something that can be done now, with relatively little effort;

Instead of making this V1 mark a physical spot/landmark (as this will be negated in a bad weather, or by a flurry of activity or whatever else), we gauge it based on a time barrier.

Let's just say for sh*ts and giggles we say that the V1 of an aircraft is 150 knots, with a VR of 160. We know the distance of the runway, and we know of the speed needed to take off. We know what we need, and we can calculate when the decision need to be made. Prior to take off, we have the non-PIC make the computations. He compares the calculations based on timed markers - at the 00:10 mark - based on rates of acceleration, we should be at this speed, at the 00:20 mark - we should be at this speed, at this time - we should be at 80 knots and make the call - at 00:30 mark - we should be at this speed.

At least until we get the technologies installed - computing based on time rather than location would be more accurate.

Now - here's where I am going to ask for your help;
-Does the non-PIC have too much on his plate as is, and so this would be too time consuming?
-Normally - are there any other speed call outs/checks done during the take-off roll?
- What obstacles are there is calculating the speed at certain times (and I understand fully that the rate of acceleration increases, and many times no-so-constantly), that might make these calculations too difficult for humans to do/use?

[Gabriel]

Take-off performance monitoring techniques

There have been a number of recommendations issued by international investigation agencies since 1971 regarding the development of take-off performance monitoring systems to assist flight crew in their decision making during the take-off roll (refer Appendix F). A number of organisations have also FLEX temp input examined automated methods for monitoring take-off performance, since as long ago as 1954.

Antecedent of recommendations for TOPMS (Take-off performance monitoring systems)
Featuring the famous Florida Air in the Potomac.

McDonnell Douglas DC-8: November 1970

Location: Anchorage, United States (US)
On 27 November 1970 a McDonnell Douglas DC-8-63F, registered N4909C, with 10 crew and 219 passengers, overran runway 06R at while taking off at Anchorage International Airport, Alaska. The overrun was determined to be due to high frictional drag caused by all main landing wheels not rotating. This resulted in 46 passengers and one cabin crew member sustaining fatal injuries, and the destruction of the aircraft. As a result of this accident, on 20 January 1971 the US National Transportation Safety Board (NTSB) issued the following recommendation to the US Federal Aviation Administration (FAA):

Federal Aviation Administration determine and implement takeoff procedures
that will provide the flight crew with time or distance reference to enable him
to make appropriate judgment with regard to the airplane's acceleration rate to
the V1 speed, particularly for critical length runways, and for runway surface
conditions that may impede acceleration [Recommendation A-71-003].

On 2 February 1973, the NTSB further evaluated the recommendation and decided that it had been superseded by recommendations issued on 3 January 1972 relating to an accident during takeoff at San Francisco in 1971 (see below).

Boeing 747: July 1971

Location: San Francisco, US
On 30 July 1971 a Boeing 747-121, registered N747PA, with 19 crew and 199 passengers, collided with the Approach Light System (ALS) structure while taking off from runway 01R at San Francisco International Airport, California. The flight crew continued the takeoff and, after an in-flight inspection for damage, dumped fuel and returned for a landing at San Francisco. The aircraft had been
dispatched for a departure from a closed runway and, upon changing to an open runway, the crew did not recompute the proper reference speeds for takeoff under the existing conditions. Two passengers were injured during the impact with the ALS and eight others sustained serious back injuries during the evacuation after the landing.
On 3 January 1972, the NTSB issued five recommendations to the FAA during the investigation into this accident including the following two recommendations relating to flight crew awareness of take-off performance:

3. require the installation of runway distance markers at all civil airports
where air carrier aircraft are authorized to operate [Recommendation A-72-003].
4. require the use of takeoff procedures which will provide the flight crew
with time and distance reference to associate with acceleration to v1 speed
[Recommendation A-72-004].

The NTSB closed both recommendations on 16 September 1977 with the FAA response to recommendation No 3 being notated ‘unacceptable action’.

McDonnell Douglas DC-10: September 1980

Location: London Heathrow, United Kingdom (UK)
On 16 September 1980 a McDonnell Douglas DC-10-30, N83NA, with 17 crew and 220 passengers, sustained a tyre burst during the take-off run on runway 28R at London Heathrow Airport. The tyre burst was observed by the occupants of a runway clearance vehicle parked to one side of the runway, who transmitted the information to the control tower. This message was overheard by the aircraft commander who, as a result, rejected the takeoff at 168 kts, which was 8 kts above the calculated V1 speed of 160 kts. The crew brought the aircraft to a stop about 110 m before the end of the runway. A successful evacuation was carried out using the escape slides on the left side, although one passenger suffered a broken leg. Two localised fires, which had developed in the centre and right wheel bogies, were extinguished by the Airport Fire Service. The then UK Accidents Investigation Branch (AIB) issued the following
recommendation in the investigation report dated 12 July 1982:

It is recommended that:
Development of a ‘take-off performance monitor’, with a cockpit display, be
undertaken as a matter of urgency [Recommendation 4.15].

The UK Civil Aviation Authority responses to AAIB recommendation received up to 31 December 1989 were published in Civil Aviation Publication (CAP) 593 Air Accidents Investigation Branch (AAIB) Recommendations: Progress Report 1990. The progress report stated in relation to the above recommendation:

A reliable ‘take-off performance monitor’ in the cockpit would undoubtedly
ease the pilots task during the ground run and the CAA would welcome the
introduction of such an instrument. Efforts to develop an acceptable monitor
have been underway for a number of years but, unfortunately, it appears that it
may take some time before one is produced.

Boeing 737: January 1982

Location: Washington, US
On 13 January 1982 a Boeing 737-222, registered N62AF, with five crew and 74 passengers on board, impacted the 14th Street Bridge and descended into the Potomac River after a takeoff from runway 36 at Washington National Airport, Washington, D.C. The aircraft came to rest in the water beyond the western side of the bridge about 0.75 NM (1.4 km) from the departure end of runway 36. Four passengers and one crewmember survived the accident. Four people in vehicles on the bridge sustained fatal injuries. The NTSB determined that the accident resulted from the flight crew’s failure to use engine anti-ice during ground operation and takeoff, their decision to take off with snow/ice on the airfoil surfaces of the aircraft, and the captain’s failure to reject the takeoff during the early stage when his attention was called to anomalous engine instrument readings. While the NTSB did not issue any specific recommendations in relation to take-off performance monitoring, it reiterated Safety Recommendation A-72-003 (see above) regarding the installation of runway distance markers. As a result of this accident and another accident ten days later at Boston (see below) a Joint Aviation/Industry Landing and Takeoff Performance Task Group was formed to examine the concept of a take-off performance monitoring system.

McDonnell Douglas DC-10: January 1982

Location: Boston, US
On 23 January 1982 a McDonnell Douglas DC-10-30CF, registered N113WA, with 12 crew and 200 passengers on board, touched down 2,800 ft (853 m) beyond the displaced threshold of runway 15R at Boston-Logan International Airport. During the landing roll the aircraft veered to avoid the approach light pier at the departure end of the runway and slid into the shallow water of Boston Harbour. The nose
section separated from the forward fuselage as the aircraft dropped from the shore embankment. The NTSB determined that the accident resulted from the minimal braking effectiveness on the ice-covered runway. Two passengers were not found and were presumed dead. The other people on board evacuated the aircraft safely but with some injuries. On 23 December 1982, the NTSB issued 18 recommendations to the FAA as a result of the investigation into this accident including the following recommendation relating to flight crew awareness of take-off performance:

Convene an industry-government group which includes the National
Aeronautics and Space Administration to define a program for the
development of a reliable takeoff acceleration monitoring system
[Recommendation A-82-169]

The FAA requested the Society of Automotive Engineers (SAE) to form an ad hoc committee to establish the requirements for a take-off performance monitoring system. In October 1987 the Society released SAE Aerospace Standard AS 8044, Takeoff Performance Monitor (TOPM) System, Airplane, Minimum Performance Standard for, which established a standard for TOPM systems, including the technical requirements and sampling and methods of test or inspection. The NTSB noted the release of the SAE standard and evaluated the FAA advice of 5 May 1987 regarding the SAE activities. The NTSB advised the FAA on 1 April 1988 that it was closing recommendation A-82-169 with the FAA response being considered as ‘Acceptable Action’.

McDonnell Douglas MD-82: March 1994

Location: New York, US
On 2 March 1994, a McDonnell Douglas MD-82, registered N18835 with 6 crew and 110 passengers on board, sustained substantial damage following a rejected takeoff roll on runway 13 at LaGuardia Airport, Flushing, New York. The aircraft overran the runway and came to rest on a dyke. There were no fatalities or serious injuries but one flight crew member and 29 passengers sustained minor injuries
during the evacuation of the aircraft. The NTSB determined that the accident resulted from the flight crew’s failure to turn on the pitot/static heat system and their untimely response to anomalous airspeed indications with the consequent rejection of the takeoff at an actual speed of 5 kts above V1. The NTSB issued an investigation report into the accident on 14 March 1996. The report contained six recommendations to the FAA including the following three recommendations relating to the monitoring of take-off performance:

Require manufacturers of airplanes operated by air carriers to publish and
distribute to operators specific elapsed times to target speeds (given normal
acceleration, the times to given airspeeds) [Recommendation A-95-18].

Require that the elapsed times to target speeds be incorporated as part of the
takeoff performance data available to air carrier flightcrews [Recommendation
A-95-19].

Require that air carrier rejected takeoff training include elapsed time to target
speed takeoff performance data [Recommendation A-95-20].

The FAA advised the NTSB on 28 February 1996 that it ‘ ... continues to believe that requiring a time/speed check during takeoff may result in unnecessary and potentially hazardous rejected takeoffs and increase flightcrew workload ... It [FAA] plans no further action on these recommendations’. The NTSB closed the three recommendations on 14 May 1996 with the FAA response to the recommendations being considered as ‘unacceptable action’. The Board stated that it ‘ ... continues to believe that until a takeoff performance system is developed, the use of time/speed checks would add an additional level of safety to takeoff performance without adding additional monitoring burdens to flightcrews’.

Boeing 747: October 2004

Location: Halifax, Canada
On 14 October 2004, a Boeing 747-244SF, registered 9G-MKJ, attempted to take off from runway 24 at the Halifax International Airport. The aircraft overshot the end of the runway for a distance of 825 ft (251 m), became airborne for 325 ft, then struck an earth mound. The aircraft’s tail section broke away from the fuselage, and the aircraft remained in the air for another 1,200 ft before it struck terrain and burst into flames. The aircraft was destroyed by impact forces and a severe post-crash fire. All seven crew members were fatally injured. The Transportation Safety Board of Canada (TSB) found that the accident resulted from a flight crew member not recognising that the laptop computer used to calculate the take-off performance data contained an incorrect aircraft weight from
the previous flight. This incorrect weight was used to calculate performance data for the takeoff from Halifax, which resulted in incorrect take-off speeds and thrust settings being generated by the laptop computer. The crew then used the incorrect speeds and thrust settings which were too low to enable the aircraft to take off safely for the actual weight of the aircraft. The Canadian TSB issued the following recommendation in the investigation report released on 29 June 2006:

Therefore, the Board recommends that:
The Department of Transport, in conjunction with the International Civil
Aviation Organization, the Federal Aviation Administration, the European
Aviation Safety Agency, and other regulatory organizations, establish a
requirement for transport category aircraft to be equipped with a take-off
performance monitoring system that would provide flight crews with an
accurate and timely indication of inadequate take-off performance
[Recommendation A06-07].

In 2007 the Canadian regulator, Transport Canada, formed a project team to examine the issue of a take-off performance monitoring system (TOPMS). In February 2009 Transport Canada tasked the National Research Council (NRC) of Canada to conduct a study into the background, technology, issues and certificatability associated with TOPMS. The NRC released a report on the technology status of TOPMS in April 2009. The report contained a proposal for a flight research and evaluation project to be conducted in the Council’s Dassault Falcon 20 aircraft to ascertain the certificatability of current TOPM technology. This research and evaluation project did not proceed due to lack of funding and no further progress has been made regarding the TOPMS issue at the time of publishing this investigation report. On 9 March 2011 the TSB noted that:

The Board is concerned that TC [Transport Canada] has ended its research
into TOPM technology. While the Board understands the complexity
associated with such an undertaking, the fact that similar occurrences happen
on a regular basis means that a mitigation strategy has to be developed.
Because this is a global issue, the Board strongly encourages TC to continue
its leadership in TOPM research but to also approach other agencies that
could contribute resources.
However, at this date, the TC has stopped all work on TPMS [take-off
performance monitoring system] technology and will only revisit this issue
when a certifiable product is developed. This action plan will not substantially
reduce or eliminate the safety deficiency.
Therefore, the Board assesses TC’s response as Unsatisfactory

Airbus A330: October 2008

Location: Montego Bay, Jamaica
On 28 October 2008, an Airbus A330-243, registered G-OJMC, with 13 crew and 318 passengers, was taking off from runway 07 at Montego Bay/Sangster International Airport, Jamaica. Following the first officer’s call to ‘rotate’, the captain pulled back on the sidestick and pitched the aircraft to about 10° nose up but the aircraft did not become airborne as expected. The captain then selected TO/GA
power and the aircraft became airborne, climbed away safely, and the flight continued to the scheduled destination. The UK AAIB investigation into the incident found that incorrect speeds were used for the takeoff due to an error in the take-off performance calculations. While the exact source of the error could not be determined, the investigation found deficiencies in the operator’s procedures for calculating performance using their computerised performance tool. The AAIB report into the incident, released in November 2009, stated that:

A system which actively monitors takeoff performance can add an additional
safety net, independent of data input by flight crews. However, despite being
identified as having a positive impact, little or no progress has been made in
the development of takeoff performance monitoring systems in recent years.
Such a system would require a high level of maturity before being introduced
to avoid unnecessary and potentially unsafe crew actions.
As a consequence, the following recommendations are made:

Safety Recommendation 2009-080
It is recommended that the European Aviation Safety Agency develop a
specification for an aircraft takeoff performance monitoring system which
provides a timely alert to flight crews when achieved takeoff performance is
inadequate for given aircraft configurations and airfield conditions.

Safety Recommendation 2009-081

It is recommended that the European Aviation Safety Agency establish a
requirement for transport category aircraft to be equipped with a takeoff
performance monitoring system which provides a timely alert to flight crews
when achieved takeoff performance is inadequate for given aircraft
configurations and airfield conditions.

On 7 July and 27 September 2011, the European Aviation Safety Agency (EASA) responded to the above recommendations by advising the AAIB that the Agency considered the feasibility of a take-off performance monitoring system had not been demonstrated and that the Agency did not intend to establish a certification specification ‘at this time’. The Agency also advised that the issue:

...has been proposed to be added to the European Organization for Civil
Aviation Equipment (EUROCAE) Technical Work Programme. It is expected
that a working group of experts will review the state of the art on the
feasibility of such system. If it appears that technology is available, then the
working group would propose a standard.

Airbus A340: December 2009

Location: London Heathrow, UK
On 12 December 2009, an Airbus A340-642, registered G-VYOU, with 16 crew and 282 passengers, was taking off from London Heathrow Airport, UK. During the take-off roll the handling pilot ‘ ... noticed that the acceleration was slightly lower than it should have been but did not consider it particularly abnormal’. The aircraft was also slow to rotate and the initial climb performance was degraded with a low rate of climb at between 500 and 600 ft/min. The UK AAIB investigation into the incident found that:

During pre-flight preparations, the estimated landing weight was used to
calculate takeoff performance rather than the takeoff weight. The error was
not detected and the aircraft took off using values for VR and V2 that were
significantly lower than those required for the actual takeoff weight.

The AAIB investigation report referred to the two recommendations regarding take-off performance monitoring systems that were issued following the G-OJMC incident at Montego Bay in 2008. The AAIB stated that:

At the time of writing [June 2010], the AAIB had not received a detailed
response from the EASA [European Aviation Safety Agency] regarding the
recommendations but their nature is such that it will probably be a
considerable time before a solution is operational. In the meantime, the Green
Dot gross error check should provide a way to highlight that an error has been
made in time for it to be investigated before departure.

As noted in the previous sub-section, in 2011 the AAIB received responses from EASA regarding the G-OJMC investigation recommendations.

And of course we also have the ATSB recommendations regarding the EK accident:

The Australian Transport Safety Bureau recommends that the United States Federal Aviation Administration take action to address the existing take-off certification standards, which are based on the attainment of the take-off reference speeds, and flight crew training that was based on the monitoring of and responding to those speeds, and do not provide crews with a means to detect degraded take-off acceleration.

(Note: a similar recommendation was not issued to the EASA because the EASA informed the ATSB that they were already working on the TOPMS issue)

Histroy of TOPMS:

Take-off performance monitoring systems

The concept of onboard take-off performance monitoring systems (TOPMS) has been proposed since the 1950s and the system has been the subject of over 30 US patents during the period from 1956 to 2007. Several organisations, including the US National Aeronautics and Space Administration, Cranfield University in the UK, the Dutch National Aerospace Laboratory (NLR), the University of Saskatchewan, Canada and Risø National Laboratory, Denmark have conducted research into TOPMS including the development and testing of prototypes. At the time of publication of this investigation report, there was no commercially available system for use in civil transport aircraft.

I'd say it time already.

[Gabriel]

Here's something that can be done now, with relatively little effort;

Instead of making this V1 mark a physical spot/landmark (as this will be negated in a bad weather, or by a flurry of activity or whatever else), we gauge it based on a time barrier.

Let's just say for sh*ts and giggles we say that the V1 of an aircraft is 150 knots, with a VR of 160. We know the distance of the runway, and we know of the speed needed to take off. We know what we need, and we can calculate when the decision need to be made. Prior to take off, we have the non-PIC make the computations. He compares the calculations based on timed markers - at the 00:10 mark - based on rates of acceleration, we should be at this speed, at the 00:20 mark - we should be at this speed, at this time - we should be at 80 knots and make the call - at 00:30 mark - we should be at this speed.

At least until we get the technologies installed - computing based on time rather than location would be more accurate.

That'd be too much workload both in calculation and monitoring during the take-off.

If you want to make it outside of the airplane's systems, request each manufacturer to provide the time it should take to go from "take-off thrust set" to say 80 knots and make the NFP wear a simple Casio wristwatch that features a timer. The crew would get the "time to 80 knots" together with the take-off speeds, the NFP would enter that time in the Casio, and if the 80kts call comes together/before the "beep-beep-beep-beep", then we are good to go. If the "beep-beep-beep-beep" sounds and we have not called 80 yet, we abort.

Oh, sorry. I forgot: pilots (except I) never wear Casio. Only Tag, Rolex or Bertling.

Anyway, I am willing to wait for an automated system as proposed by Evan IF the authorities and the industry are really willing work on it. It shouldn't take more than a handful of years to develop the standards and certify the systems.

Now, we've been waiting since 1956 and the first recommendation to implement such a system after a fatal accident came in 1971.

As I've said, it's time already.

[3WE]

....snip...Could this be the longest Gabriel post ever?...snip...

Could I summarize this by saying, "Maybe the V1 method has a few flaws-as evidenced by a few crashes- and maybe there should be some sort of speed/location check (albeit done electronically)"

[Gabriel]

Could this be the longest Gabriel post ever?

Your fault.

I explained how small deviations in the acceleration (and even no deviation, but a small wind change) can have measurable effects in the take-off distances.

I mentioned that the ATSB found dozens (that's the word I used, but it was two and a half dozens "only") where wrong take-off data entry compromised safety (up to causing fatal accidents).

I mentioned how the idea of take-off performance monitoring had been around for a lot of decades and different organizations had recommended its use.

I mentioned how the data and the technology is available.

And then you came with this:

Now, given that thousands of planes take flight every day using this flawed V1 procedure- maybe it's not too bad (subtle sarcasm)- is there anything the parlour talkers need to hear about- a safety buffer? The thought that there's a high probability that a pilot would detect a performance problem? Or is Boeing Bobby right- it ain't broke so STFU and don't 'fix' it?

[...]

But to repeat- while I can see a technical advantage to a location/speed check (or the electronic equivalent), I do not see a meaningful safety improvement- so discuss, yes...propose change, no.

So I had two choices. To let it be or to bore you with compelling factual information. I chose b.

[BoeingBobby]

You mean you never looked at an airport direcftory?

http://www.airnav.com/airport/KORD

I didn't include the LD vs LDA because we were talking about take-off, not landing.

Actually I have never even heard of an airport direcftory. Sounds like some kind of religious thing to me! We use Jeppeson charts, none of that stuff on there that is not spelled out in ENGLISH. That is the official language for aviation after all.

And what is with this sweet monkey river stuff?