@Diversification
"Given the availability of technologies such as GPS, Inertial navigation,
radio navigation, radar, AOA sensors - is it possible to build an avionics
package which could automatically control (and provide pilots with
information to manually control) the flight throughout all phases without requiring a pitot-static system at all?"
Thanks for the link. Nice idea, but from the description of its limitations it sounds like it would not have been of much help. One of the principles I learnt as a systems eng is the concept of Observability and Controllability(Kalman). If the controller can't observe a system state, then the system remains stable only as long as the unobservable state is also stable. ie; if a critical data measurement such as airspeed is lost (say gets stuck at some value Vk=Vk+1 etc) but nothing else changes, then the system will appear to be stable. Perturb the system, and instability is inevitable. Some systems use an Estimator/Observer swapping system to get over transients, but these are only so good close to regions of stable Operation. Redundancy of data measurement can help, but if all are afflicted by the same malaise, then failure will ensue. Maybe an AoA sensor/ sensors is the answer. If the control system is smart enough to detect the fault, then it needs to degrade gracefully and present the human operators (the pilots) with options, and not overwhelm with information overload. Automation is only as good as the interface between it and the operator, and operator skills when applied to interaction with complex automation, only as good as the procedures (human factors influenced) laid down by the systems designers. If blame is to be apportioned, do NOT lay it in the lap of the pilots.
@deSitter
Dozy and syseng68k are correct in their assertions. APL, FORTH etc are nice tools, but are not as robust as some of the stuff used for safety critical applications - type checking etc. All done to keep the programmer from inflicting bugs on the unsuspecting. In the past I have had to use assembler for time critical embedded underwing stores Mil apps, where thecode produced from the C compiler was simply to inefficient (too slow) or the task - with faster processors, and more I/O functionality on chip, this is no longer necessary. What has not been mentioned here is that software requirements devolve down from system requirements. When I retired a few years back, there was a push in various safety critical industry sectors towards a design process where a system is modelled and simulated (hardware and software) under Matlab and auto coded by the Matlab compiler. The desired effect, theoretically, is to remove the programmer from the loop, and place more of the design task in the lap of the systems engineer. Some proponents have even suggested that simulations should produce straight raw code and forget any intermediate high level code. Nice idea if you can get it to work, but in the real world, it removes a level of validation (programmer checking the high level code),and to my mind is potentially dangerous.
@mm43
I redid the calculation, and basically it is impossible to determine from it what the terminal RoD was, as depending at what time the Advisory happened, and allowing or not ACARS queue times, the outcome can be very much different.
Tend to agree. However, have you considered a crude calc to guess how
long it would take to reach VT assuming a stall with min or zero lift from
upset to sea level.
The non linear diff equation for a falling object that experiences drag is:
mdv/dt = -m.g +1/2.Cd.p.A.v.v ...... (1)
So, with terminal VT = root(2.m.g/p.Cd.A) ......(2)
Sol is v(t) = VT.tanh(g.t/VT)
From (3) you can make an estimate of the time to reach VT for step
increments in t, and then use (2) thereafter, adjusting for density p. I
suggest a Cd of 1.2 or 1.3, or else just plug in a value, say 70m/s, for VT.