Regarding
Appropriate technology:
Pehr Hallberg says.....and PickyPerkins seconds:
There is no such thing as a complex software system without bugs in it. Combine this with filtering of the input, maybe errors in the input due to failures in the sensors and you may end up with a very strange response from the system.
Let's put this in perspective:
Sad but true, ALL systems have their inadequacies. Each and every one is cobbled together by fallible people, based on the biases and perceptions of the time, using the materials at hand at that moment, to solve a problem which is inevitably, to some degree, imperfectly understood and improperly specified.
When machines cross beyond a certain threshold of complexity, they are actually safer to build with electronics and 'software' in control than with long cables, vulnerable hydraulics or carefully hewn clockworks of steel or spruce. Manual controls are more appropriate for gliders and sailboats than for turbine passenger transport aircraft and nuclear submarines. Of course, there's likely always something mechanical at the ends of the process.
I, too, have worked in software development and testing since the 1960's as well as in electronics, computer architecture & design, and systems analysis - not a small amount of it for things like chemical refineries, vehicle and machine controls, avionics, weapons systems, very large-scale transactions systems such as used by the banking industry, telecommunications, health care, and other environments that place a high value on near-perfect operation, orderly degradation in the event of failures, and redundancy / maintainability such that they may never fail and never need to be switched off for scheduled maintenance.
By 1970, already, the state of the art of reliability and verifiability for critical process software-driven control systems was well along. The hundred-millionfold improvement since then in raw price/performance of computing and control system pieces has helped move machine reliability along much further.
The proof that these systems exist and operate is all around you - in a rather undramatic form. It is most manifest in the industrial accidents that don't happen, the odd little deviations that don't appear in your bank account, and the unintended mushroom clouds you don't see depicted on the evening news.
There is a BIG difference beteen software (and hardware) carefully developed for critical applications and those provided on a fairly casual basis by companies, such as Microsoft, which depend on inherent product bugs to motivate frequent purchases of hastily developed 'new and improved' products with new and improved bugs.
So:
Please do not frighten people unduly with global condemnation of these very useful technologies, but instead try to cite more specific relevant examples (many can be found) that are specifically worthy of criticism and improvement.
-----------
BELGIQUE - your focus on rudder specifics is very illuminating. A good job of reporting!
This information deserves much consideration. We can hope someone who knows the design specifics will share some details. I will react to a couple of points immediately:
I agree with your inference that the two yaw-damper computers SHOULD have been identical in design. Whether that actually is the case - at the circuit level - would require some heavy duty testing. One hopes the parties involved will take a forensic approach toward a determination.
The yaw-damper computers could have been physically identical but with different STORED states determining behavior - such as calibration, configuration updates, or just recent history that would be weighted in. Like ice, these states might not be preserved for later analysis. Any difference in history - which is inevitable if each is using a different collection of sensors - would cause them to operate somewhat out of phase - most of the time.
Even a single yaw-damper control could oscillate - by itself- if the s1- sensor reported aerodynamic response of the aircraft differed significantly from expected value for the s2-sensor reported angle of rudder deflection, based on the computed command signal applied to the actuator. This would produce the case where yd1 system was oscillating and the yd2 system, mechanically coupled to yd1 via the yd2s2 deflection angle sensor -whose response is delayed by the slew rate of the yd1 actuator and rudder mass - would be counter-oscillating in the effort to correct it.
Depending how implemented, I doubt that the yaw damper system 'pauses' before acting. More likely it determines a rate of control actuation which will - based on current input - lead to the desired result at some point in time future, and repeats this analysis continuously. By doing so, it never causes the full action based on a single moment in time, but accomplishes this
by the cumulative effect. This plan tends to reduce oscillation. Two controls with similar future-oriented agendas could certainly oscillate against each other if one was slow or misinformed or if both were receiving rapidly varying information which they processed in slightly differing phase.
Surely the original designers thought a lot about the possibilites for oscillation here, so it would be interesting to see what could have slipped through the cracks. My guess would be a 'minor' redesign of some critical component - actuator - angle sensor - rudder - yaw sensor - computers - calibration procedure - data path, etc. after the the original design was completed and released.