Avionics is where aerospace meets software, and it is the clearest example in this section of a field where the adjacent skill does not transfer as easily as it appears.
Not ordinary software with extra documents
A common assumption is that certified airborne software is normal software plus compliance overhead. That assumption produces failed hiring and failed programmes.
Four things that differ fundamentally.
Every line traces to a requirement. Code exists because a requirement demanded it, and that link is documented and reviewed. Code that does something sensible but is not traceable to a requirement is a finding.
Verification coverage must be demonstrated. Testing must be shown to exercise the code to a defined structural coverage level, which rises with assurance level. This shapes how code is written, because complex constructs become expensive to cover.
Determinism is required. Timing must be predictable and bounded. Dynamic memory allocation, unbounded loops and unpredictable execution paths are avoided or prohibited depending on the level.
Tools themselves require qualification. If a tool's output is trusted without independent review, the tool must be qualified. Compilers, test generators and analysis tools all fall into this.
A skilled commercial software engineer is not automatically a skilled avionics engineer. The constraints invert several habits that make someone good at ordinary software.
The consequence for hiring is specific: recruiting general software engineers into certified roles and expecting a short adjustment consistently underestimates the transition, and the engineers themselves frequently find it frustrating before it becomes satisfying.
What the direction covers
The scope: aircraft electronics, GPS, flight control, communications and onboard systems.
Four areas.
Flight control systems. The chain from pilot or autopilot input to control surface movement, including fly-by-wire architectures and their redundancy.
Navigation systems. Satellite navigation, inertial systems, air data and the fusion of all three.
Communications and surveillance. Radio, datalink, transponders and the systems that let aircraft be seen and coordinated.
Integrated architectures. How functions share computing hardware with guaranteed partitioning, so that a fault in one cannot affect another.
Why the requirements are as strict as they are
Worth explaining rather than asserting, because understanding it is what makes an engineer good at it rather than merely compliant.
Assurance requirements are driven by consequence. A function whose failure would be catastrophic carries the heaviest obligations; one whose failure is merely inconvenient carries far fewer.
That produces three practical realities.
The same function can carry different obligations. Depending on the aircraft, the architecture and what else would be available if it failed. Assurance level comes out of a safety assessment, not out of the function's name.
Architecture can reduce the burden. Designing so that a failure is detected and handled by an independent path can lower the assurance level required of a component, which is a genuine engineering trade rather than a paperwork exercise.
Change is costly. Modifying certified software means re-verifying affected parts and re-establishing evidence, which is why apparently trivial changes carry disproportionate cost and why software is frozen far earlier than commercial teams expect.
Where this sits in the domain
Avionics, navigation and aerospace systems is the fifth of nine directions in Astra Trainer's space, aerospace and new mobility domain, sitting alongside aeronautical engineering and aviation operations, and connecting to the robotics domain, where control systems covers the underlying control theory.
It also pairs with semiconductors and electronics for hardware, and with AI, data and computing for software engineering practice, though partners should note that the transition from commercial to certified software is the substance of this direction rather than a detail. You can see the nine directions here.
Navigation, and a dependency worth naming
A factual observation with real engineering consequences.
Satellite navigation has become a shared dependency for far more than aviation: shipping, road transport, surveying, agriculture, emergency services, and notably precise timing for telecommunications networks, financial systems and electricity grids.
The signals are weak by the time they reach the ground, which makes them susceptible to both unintentional interference and deliberate jamming or spoofing. Interference events affecting aviation navigation have been reported in various regions, and the aviation system handles them through procedures, alternative navigation aids and inertial systems.
Three consequences for engineering and workforce.
Alternative and complementary positioning is an active area. Inertial navigation, terrain and visual navigation, and alternative timing sources all receive attention because of this dependency.
Resilience is a design requirement rather than a feature. Systems that assume continuous satellite navigation availability are making an assumption that is not always satisfied.
The skill set is niche and growing. Engineers who understand both satellite navigation signal processing and inertial systems are scarce, and they are needed well outside aviation.
This is stated as a known engineering consideration. It is not a prediction about any specific region or event.
The roles, named
Avionics software engineers. Certified airborne software. The core scarcity.
Avionics hardware engineers. Boards, interfaces, environmental qualification.
Systems safety engineers. Safety assessment, failure analysis and assurance level allocation. Central and short.
Verification and validation engineers. Requirements-based testing and coverage analysis. The largest population in a certified programme.
Navigation systems engineers. Satellite navigation, inertial and sensor fusion.
Integration and test engineers. Rigs, iron birds and flight test instrumentation.
Certification specialists for software and complex electronic hardware.
Avionics maintenance technicians. Licensed, in service, and a separate and persistent shortage.
Who can be trained into it
Engineers from other certified-safety domains. Rail signalling, nuclear instrumentation and control, medical devices, automotive functional safety. They already accept that evidence is part of the product, which is the hardest attitude to instil, and they need the aviation-specific framework.
Embedded software engineers. From industrial or automotive backgrounds, already used to constrained, deterministic environments. A shorter step than from web or application development.
Test engineers. Into verification, which is the largest requirement in any certified programme and the most accessible entry point.
Avionics maintenance technicians. Into engineering support and integration roles, bringing knowledge of how systems behave in service that design teams frequently lack.
Electronics engineers. Into hardware and integration.
Military avionics personnel. Arrive with the systems and airworthiness culture already embedded.
Certification and licensing are legal, not procedural. Airborne systems are approved through regulatory processes, and design organisation approval, certification credit and airworthiness release are held by approved organisations and qualified signatories. Avionics maintenance requires a licence with appropriate ratings. Aviation technology is also subject to export control in most jurisdictions. Training builds engineering understanding and supports people working toward these routes. It does not confer approval, certification credit, licence or authority to release anything to service.
What to take from this
Certified software is a different craft, not ordinary software with documents, and several habits that make a good commercial engineer are constraints here.
Assurance level follows consequence, so architecture choices can genuinely reduce the burden, which makes safety assessment an engineering activity rather than an approval step.
Change is costly because evidence must be re-established, which is why software freezes earlier than commercial teams expect.
Satellite navigation is a shared dependency well beyond aviation, and resilient positioning is a growing and niche skill set.
And engineers from rail, nuclear, medical devices or automotive functional safety convert far better than general software engineers, because they already treat evidence as part of the product.
Is certified avionics software just software with more paperwork?
No. Every line traces to a requirement, verification coverage must be demonstrated structurally, timing must be deterministic, and tools themselves may require qualification. Several habits that make a good commercial engineer become constraints.
Why do assurance requirements vary?
Because they follow the consequence of failure, determined by a safety assessment. The same function can carry very different obligations depending on the architecture and what remains available if it fails.
Why is changing certified software so expensive?
Because affected verification evidence must be re-established. This is why software freezes far earlier in an aerospace programme than commercial teams expect.
Who converts into avionics roles?
Engineers from rail signalling, nuclear instrumentation, medical devices or automotive functional safety, because they already accept evidence as part of the product. Embedded software engineers are a shorter step than application developers.
Where does this fit in the domain?
Fifth of nine directions in Astra Trainer's space, aerospace and new mobility domain, connecting to control systems in robotics and to electronics in the chips domain. You can see them here.