PPRuNe Forums - View Single Post - Continental TurboProp crash inbound for Buffalo
Old 20th May 2009, 23:04
  #1391 (permalink)  
khorton
 
Join Date: Jun 2006
Location: Moses Lake, WA
Age: 63
Posts: 53
Likes: 0
Received 0 Likes on 0 Posts
I see from your profile that you are an engineering test pilot. If you work for Bombardier, could you guess at how difficult the software changes I suggested would actually be?
I work for Transport Canada, but much of my work is on various Bombardier aircraft. I've only got three flights on the Q400 though. Any posts I make here are my personal opinion, and don't represent the views of my employer.

Software changes sound easy in theory, but they are never simple in the real world. The first big question is whether the physical interfaces that you need for the new function exist. I.e., look at which box drives the speed bugs, and see whether that box has knowledge of the SPEED REFS switch position. If not, then you need to find a way to get that info into the box. If you need to add new physical interfaces (i.e. new wires), then the cost and complexity go through the roof. But even if you don't need new wires, if the box that drives the speed bug does not already have knowledge of the SPEED REFS switch position, then you need to look at which other boxes you can pass the info through, and you might need to change the software in each of these boxes to pass the SPEED REFS switch position onwards, to eventually get the info where it needs to be.

Then, you need to fully define exactly how the new software will work, and there are always a multitude of corner cases to consider. Then the vendor has to write all the code that does the work, and it must be extensively tested. Usually there are bugs, which means more code writing and more testing.

To further complicate things, all the new code must be developed in accordance with a very formal software development process, that attempts to ensure the final software does exactly what it is designed to do. This is a laudable goal, but the required process is very expensive to implement.

But we still have my original comment to resolve - if the bugged Vref could end up higher than originally set by the crew, then they need to have calculated landing performance that accommodates that possibility. If I understand your proposal correctly, you want the bugged Vref to automatically be increased to cover flap angles lower than planned, and/or SPEED REFS switch in INCR, when the crew's intention was flap 35 and SPEED REFS to OFF. I don't have Q400 landing performance at hand, but there must be quite a large difference in Vref between Flap 35 + SPEED REFS to OFF, and Flap 15 and SPEED REFS to INCR. As a first order approximation, for every 10% increase in speed you can figure on a 20% increase in required field length.

Maybe operators on long runways could live with always using a landing field length that assumed minimal flap + SPEED REFS to INCR, but there are operators who actually go into shorter strips. Consider Porter Airlines, who fly into Toronto City Centre (CYTZ), with a 4000 ft long runway (1219 m).
khorton is offline