AbsInt
Proving Software Safety for Aerospace Certification

Aviation software can pass extensive test campaigns and still leave unanswered questions about behaviour on paths that testing never exercises. For avionics programs, that gap reaches beyond defect discovery. Verification evidence must remain credible under certification review, while engineering teams cannot afford tools that add a second development process beside the one already in use. Static analysis, therefore, has to do more than flag suspicious code. It has to produce evidence that engineers can defend.  Coverage is the first pressure point. Test suites are bounded by the cases that engineers design and the conditions they can reproduce. Static analysis should reason across program paths and possible inputs without depending on a particular test run. The distinction matters most around infrequent runtime faults and execution-time behaviour that may surface only under unusual states. A tool that reports broad findings but cannot establish why a result is sound leaves verification teams with another review burden. Buyers should examine how the analysis handles uncertainty and whether its conclusions are mathematically grounded. Potential issues should also be traceable to code.  Certification changes the economics of that technical rigour. Results have limited procurement value if teams must manually reconstruct the evidence needed for DO-178C review. Formal methods can strengthen verification under DO-333, while tool qualification requirements introduce their own documentation burden. Useful software should therefore connect analysis results to qualification artefacts that fit the program’s certification plan. Traceability matters here, but packaging matters too. Evidence needs to move into established review material without creating a separate chain of documentation that engineering and certification teams must reconcile late in the program.  Technical fit can be just as decisive. Aerospace programs often retain processor and compiler dependencies across long-lived build environments that cannot be replaced merely to accommodate a verification product. Analysis software has to work across the target environment while preserving the existing toolchain wherever possible. Integration with continuous-integration systems and engineering tools is especially important because static analysis loses practical value when it is treated as an isolated gate near release. Buyers should look for automation that can be repeated as code changes and target support that adapts without destabilising the verification process.  “AbsInt’s Qualification Support Kits provide structured qualification evidence that can be incorporated into certification documentation without forcing teams to build a parallel verification process.” These pressures narrow the field. Strong products make sound analysis usable as certification-ready evidence. That work must also fit the software process already governing the aircraft program. The decisive question is not how many warnings a tool can produce. It is whether engineers can use its conclusions as dependable verification evidence without turning certification into a parallel engineering project.  Against that standard, AbsInt merits consideration as a premier choice for aviation safety-critical static analysis. Its analysis framework is built around mathematically sound results and can be adapted to varied processors and compilers. AbsInt’s Qualification Support Kits provide structured qualification evidence that can be incorporated into certification documentation without forcing teams to build a parallel verification process. Its Astrée software analyses runtime errors, while StackAnalyzer addresses worst-case stack use, extending verification beyond what test execution alone can cover. Batch workflows and established development-tool integrations further reduce adoption friction for aerospace teams that need stronger proof without replacing their existing environment.  ...Read more