From aerospace engineering to printer problems

Development of a flying system from any kind is a fascinating process. Mainly because of the complexity of the problems and the inherent risk of flight. In general, everything can go much worse when flying is included. Consider the last time you tried to print something; you would typically go through the same process as an aircraft developer would go through. Just like a NASA scientist, you hypothesize on what will happen (a normally printed page) perform the test (send a file to the printer), collect and analyze the results (examine what was supposed to be a printed document and wonder what went wrong).  

So, for aerospace development, the process is quite the same. Well, apart from one difference, when you are at the office running between your desk and the printer trying to “test” the printer. You do not consider the option that you only have one chance. And that if you get it wrong, the printer will climb to the top of the building and jump right off. This in assents is the biggest challenge in aerospace development, Systems that usually are amazingly, almost magically flying through the air have the inherent habit (thanks to Sir Isaac) to smash into the ground in a real effort to hide whatever it is that went wrong.

Along the past years through multiple developments and testing cycles, I think I can pinpoint a few critical principles that will be relevant to any development. As the price for mistakes in aerospace is so high, the effectiveness of the development process has been refined to a very high degree in ordr to minimize mistakes and maximize the effectiveness. And as such, using the same principles for any development can streamline the process and reduce the risk of costly errors. 

What is the question? Be specific.

Probably the most important question in any testing process is to define what we are trying to achieve. A specific set of questions will result in a specific path while a different set will result in a totally different testing process that might validate other parameters. As it is usually the case with flight testing, every system that is being tested have different aspects, and each one might dictate a different test setup to get specific measurements. 

For example; when attempting to measure and quantify the performance of a communication system, your measurement will be limited by the weakest link, it might be the ground-based radio, the radio on the aircraft or even, if we dive deeper, the specific transmitter location, antenna placement or the quality of the cables. Every parameter might play a role, and the more specific you will be, the more relevant the results are by giving you the correct information to make a better knowledge-based decision.     

What are you measuring?

Probably one of the most critical steps is to understand what does the sensor system measures. The difference between what you think you are measuring and what is being recorded might vary dramatically due to the measuring system setup, local physical phenomena, calibration offsets and system sensitivities. This is a classic case of “garbage in garbage out”, where because the measurement method was not fully understood the recorded results could vary significantly from the actual measured phenomena.  

For example; The next time you are driving a car look at the speedometer and consider the fact that the indicated speed might be very different from your actual ground speed. Don’t believe me? Check with a GPS. In fact, your perception of the car’s speed might be influenced by everything from the angle you are sitting in, the accuracy of your speedometer, intentionally induced offsets and also your tire’s pressure. In total the offset of all the parameters might come up to 10% of your actual speed.

Block the problem by solving a simplified one

From designing the process to analyzing the results, a good way to simplify a complex problem is to solve a simpler problem, that by definition will “block” the real one. Meaning, the results from the new less complex problem will by design, be positively or negatively offseted from the real problem. In this way, you could conduct a simpler test and still get the required results, which is to have the right data in order to make a desition.

For example; When trying to validate that a drone propulsion system will not overheat, performing the test on the ground (and not in flight) will limit the natural cooling of the system due to the airflow. If successful, the results of the test will prove that the system can withstand overheating at any flight condition. However, if the system will fail the test, it will be a “no-test” where the results cannot prove or disprove the performance of the system.              

 In summary

Following the described basic steps will definitely help to better define and streamline the development of any system, whether it's aerial, robotics or software. By asking the right questions at the right time, the development process will become infinitely faster. And more importantly, it will reduce the number of design cycles and pointless testing, which is the main time consumer of any development project.