A new computer engineering graduate who started working at an avionics company last week was given documents such as DO-178C to read. As you might guess, this is rather boring, and he asked me how he could make the initial learning phase more interesting. He is already using NotebookLM to convert the documents to audio and to ask questions.
Since avionics involves safety-critical software development, where we don’t just care whether the code works but also how it fails, I suggested that he write a toy software project in which he simulates sensors (such as an angle-of-attack sensor) and asks an AI about typical failure conditions. The sensors might produce out-of-range values, stop working for some time and then start again, they could stay within bounds but have sudden jumps (e.g. GPS positions under spoofing) and so on. On sensor error, his code should first enter a degraded mode (using the previous good value and displaying a warning message) and, if the sensor error persists, transition to a safe mode (displaying an error message). He could then ask the AI which types of hardware defects can be detected by software (hint: Error Correction Code). This exercise would make the concepts of safety-critical software development more concrete.
The next step would be to understand how avionics sensors actually work, which would increase his domain knowledge. Adding simple mathematical models for the sensors and a bit of digital signal processing to his toy project would also be a very useful learning experience.
He could ask experienced engineers at his company how they arrived at the safety level for the system they are currently developing. What kinds of hazards did they take into account? How did they calculate their probability values?
For more low level topics, he could look into hard real-time concerns, such as interrupt latency and jitter, how cache misses, pipelining, and branch prediction adversely affect determinism and worst-case execution time (WCET).
Lastly, he could read about or watch analyses of software and aircraft failures to get an idea of how systems fail. For example, he could ask AI why the Boeing 737 MAX MCAS did not use both angle-of-attack sensors, despite the aircraft already having two. Finally, he could ask whether a relatively simple solution could have been found while staying within the original cost constraints. One possible answer for MCAS might be: if the designers had limited MCAS to a single input and ensured that it disengaged when the pilot pulled back on the yoke, it would have preserved the commonality assumption in normal flight while also preventing the catastrophic failure mode.
Avionics is a fascinating field, offering endless opportunities for exploration. By being curious and working hard, he can become a valuable engineer who not only solves problems correctly but can also spot problems worth solving within a few years.
Music: Khaled - Aicha
