46 SEPTEMBER 2025 WorldWide Drilling Resource® What a Computer Can or Cannot Do by Britt Storkson Owner, P2FlowLLC With the news of the Air India Flight 171 Boeing 787-8 Dreamliner bound for London, England, crashing - as with every major airplane disaster - there has been a lot of speculation regarding what went wrong to bring that airplane down in a residential area less than a minute after takeoff. I should state I do not have any inside information or any information in addition to what is available in new reports, so this is all speculation on my part. I also do not know much about aviation, but I know quite a bit about how computers do and don’t work. I will comment on what role, if any, the computers could have in causing a crash such as this. There are many theories about what caused that crash right now. One theory is both engines stopped for unknown reasons. The question then arises: Could a computer flaw or glitch have been responsible for this action or inaction? The answer is a qualified “yes,” but it depends on how the computer system was designed and what it was tasked to do. One news report stated one of the pilots switched off the fuel to the engines and it caused the crash. From what I’ve read, the fuel on/off switches need a deliberate mechanical two-step operation to prevent accidental shutoff. The unknown here is did these fuel switches directly control the fuel going to the engines, or did the switch signal go through the computer controlling everything which, in the case of this Boeing 787, was the Full Authority Digital Engine Control (FADEC) which then directed the fuel valve to turn on or off? Due to the current (amperage) load the fuel switches controlled, the switches likely activated relays which controlled the power going to the fuel valves, but these relays don’t appear to be a factor. With most computers, just because you press a button or turn a switch, doesn’t mean the device will always do or not do something. Almost always, the switch press/button push is routed to the software, which decides if or when to turn something on or off. Often, the computer implements time delays for stability before turning something on or off, which works very well to reject spurious signals. The computer may have a long delay to turn something on and a short delay to turn it off, so the operator will get an almost immediate response if it needs to turn it off due to a malfunction, before costly damage can take place. The computer may also require a series of specific commands be performed before turning something on or off. Do computers ever make errors? Yes they do. Not many errors, but they do make errors from time to time. One way to deal with this is to write the software in such a way that the computer detects and rejects these errors. One error-reducing technique is redundancy: Perform the same test over and over again and “majority rules.” If during this test we get, say, 20 results indicating one thing and one result indicating something else, then it is safe to assume the 20 same results are the correct answer. Another way to ensure accuracy and reliability is to collect a number of samples, then average the total. This operation tends to reject the extreme high and low figures (which are probably erroneous) to get an accurate average. This is most often used for sensors - like temperature and pressure sensors. These sensors output an analog (variable) voltage which is converted into a digital (1s and 0s) “word” so the computer can use it. To average, let’s say 16 samples, one adds 16 samples together then divides by 16 to get the correct number. Any number of samples can be averaged with the more samples providing more accuracy. All of this happens in a very short time, so if something is wrong it can quickly be detected and corrected . . . if the software is there to correct it. What is my take on the cause of this crash? Again, this is only speculation given the information I have at this time. One factor is deliberate overcomplexity, which I think is a serious problem with the computer industry as a whole. That is, building the computer only to make it more expensive instead of making it better or more reliable. You would be amazed to know how very little software can provide a lot in the way of control functions. Software over and above what’s actually needed greatly increases costs and makes testing and troubleshooting far more difficult. Another factor is inadequate or nonexistent testing under all conditions . . . a problem which is exacerbated by the abovementioned overcomplexity. And a third factor/problem is making the operators (in this case the pilots) computer babysitters who are constantly checking on the computer when the computer should be checking on and verifying the operators - not flying the plane, because that’s the job of the pilots - but checking on and offering corrections to the pilots if something is not right. Britt Britt Storkson may be contacted via e-mail to michele@ worldwidedrillingresource.com
RkJQdWJsaXNoZXIy NDk4Mzk=