Aerospace & Defense
Nothing is certified on intent. Every objective needs evidence behind it.
Your software is certified against objectives, not features. Each one needs evidence that a certification authority — or a prime contractor acting as one — can audit line by line, and the rigor rises with the consequence of failure. It applies again to every change, for the service life of the platform.
Programs run long, supply chains run deep, and critical code is written several tiers down. Wherever the work happens, the obligation to prove compliance remains yours.
Three recur on civil and defense programs alike — at every design assurance level.
The highest assurance levels require verification performed independently of development. Staffing that from the same organization, under the same schedule, is possible on paper and difficult in practice.
A modification to certified software reopens the question of what else it touches. Impact analysis and regression evidence decide whether a change takes weeks or reopens a certification effort.
Code generators, model-based development and automated verification save effort only if their output can be trusted. Qualifying the toolchain is a body of evidence in its own right, and one that is routinely underestimated during program planning.
You answer to civil airworthiness authorities, military certification regimes, or both on the same platform — and now to aviation information security rules as well. Security is expected to be built into the system lifecycle rather than added at the end, and the evidence has to reach the people making the acceptance decision — including where agentic AI is part of the system.
Software considerations in airborne systems: objectives scaled by design assurance level from A to E, with independence required at the most critical levels.
Design assurance for airborne electronic hardware, including programmable devices.
Aircraft and system development and safety assessment — the processes that set the assurance level the software inherits.
EMAR and national military regimes adapt the civil standards, with requirements set by the certifying national authority.
Information security management for design, production and operating organizations, applicable since 2025 and 2026, alongside the airworthiness security process for aircraft systems.
Supplements covering tool qualification, model-based development and object-oriented technologies.
At the higher design assurance levels, the standard asks for independence. These three engagements are how we supply it.
Verification against DO-178C and DO-254 at the objective level, with independence that is structural rather than arranged — we have no delivery stake in the program we are reviewing.
- Requirements, design, code and test reviewed against the objectives your DAL carries
- Structural coverage analysis, including the code your tests never reach
Independent verification across the system and not only the software: ARP4754B allocation, ARP4761A safety analysis, and the interfaces where the two are supposed to meet.
- System and software evidence reviewed as a single argument
- Change impact assessed before a certified baseline is reopened
The evidence assembled for the people who make the decision — a certification authority, a qualification authority, or a customer’s own airworthiness organization.
- Tool qualification evidence under DO-330 for generators and automated test tools
- Part-IS and DO-326A security activities placed inside the lifecycle rather than after it
A shift away from rigid multi-year delivery toward continuous, assured updates that reach the tactical edge safely — with human and AI teaming kept visible and under oversight.
Where our work in airborne and mission systems concentrates.
Served as technical lead developing official guidelines for defense DevSecOps, secure cloud access, and secure container and Kubernetes deployment reference architectures.
Pioneered research on DevSecOps in embedded, high-assurance systems, including the published papers “DevOps in Embedded Systems: An Empirical Study” and “Applied Industrial DevOps 2.0”.
Objective-level verification for airborne software and complex electronic hardware, at every design assurance level.
Development assurance and safety assessment at aircraft and system level, where most of the argument is actually decided.
Evidence for the code generators, analyzers and test tools your process depends on.
Part-IS and DO-326A / ED-202A security activities assessed inside the development lifecycle.
Assessment of agentic and learning components where the evidence has to reach the authority making the acceptance decision, including whether human oversight can actually intervene.