Certification Considerations for Flight Critical Complex Non-traditionally Developed Software

When trying to reconcile the addition of non-traditionally developed software (e.g., Artificial Intelligence (AI), machine learning (ML), and other complex software) to flight and safety critical applications, the question of certification of the non-traditionally developed software is a difficult one to address and answer. First, the guidance for what might be expected for certification of such software is often unknown or in development, where the expected processes, objectives, and activities are uncertain. Second, there is a question of whether certification, even once those processes, objectives, and activities are identified, will be adequate or even possible given some of the potentially unique and non-deterministic aspects of the non-traditionally developed software. Third, instead of certification can mitigations [e.g., interlock, inhibit, interrupt (i.e., run-time assurance, or doer/checker), or limiter] only be applied, and therefore forego certification all together of their non-traditionally developed software. This paper explores the third question, while also considering the previous two: (1) what might be expected of non-traditionally developed software, and (2) adequacy of those expectations.