The US federal aviation regulation FAR 91.3 states:
The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of the aircraft.
Over the years a recurring question raised about the design of FBW aircraft has been whether pilots constrained by software embedded protection laws really have the authority to do what is necessary to avoid an accident.
But this question falls into the trap of characterising the software as an entity in and of itself. The real question is should the engineer who developed the software, and whose avatar the software is, be the final authority?
An example to illustrate
Say that a passenger aircraft is g limited to prevent overstressing the airframe during a high speed upset, the g limit is set at 2.5g the airframe design limit is known to be 3g and the actual airframe survival (but bent) g limit is nominally 4.5g.
Through no fault of their own the pilots of the so designed aircraft encounter a high speed upset and attempt to recover the aircraft at the 2.5g hard limit. Unfortunately the altitude lost during the encounter is such that the aircraft impacts the ground with the loss of all onboard. The subsequent accident investigation finds that if a manoeuvre of 3.2 g or 0.7g outside the 2.5 g limit had been made the aircraft would have recovered successfully, with some airframe damage.
So the pilots knew what they had to do, but the software prevented them from doing it. Software that was, as it turns out, approved by the chief engineer for flight controls at manufacturer X. Is the chief engineer now responsible for the safety of the crew and passengers? The software certainly isn’t, software after all is insensate. It acts but is not an actor.
But, recounts the chief engineer for flight controls I was given a specification to develop my software solution against. So I cannot be held accountable surely as I did not write the specification, that was the systems engineers responsibility…
So who here has the ethical (and legal) obligation?
To my mind for software, where a precise specification of desired behaviour is required, the systems engineer (or other specifier) must take responsibility for missing, ambiguous or just plain wrong requirements.
In fact my belief is that such a person is as responsible as if he had been personally sitting in the cockpit, for in a very real sense that’s exactly what he’s doing.