耐空証明ハンドブック
(Airworthiness Handbook)

耐空証明のビジネスへの影響：次世代航空電子機器ソフトウェアの認証における課題の克服

民間および軍用航空電子機器メーカーは、劇的な市場の変化に直面しています。その課題には、サイバーセキュリティの脅威の拡大、持続可能性と自律性の進歩、先進の航空機動性といった新市場の台頭などに対応することがあります。こうした需要の増加は、過去50年間で航空電子機器ソフトウェアの量と複雑さが4年ごとにほぼ倍増してきた傾向の延長線上にあります[1]。航空電子機器企業が新たな市場と機会を模索するにつれ、実現できる機能の大部分は、ますます洗練されたソフトウェアによってもたらされるようになります。
 
重要なシステムを故障や攻撃から保護するために、十分な安全性とセキュリティ、つまり耐空性を確保するために取り組んでいる開発チームは、耐空証明という目標を達成するためのコスト、時間、労力が比例して増加していることに気づいています。以下にあげる厳しく変化する状況は、ソフトウェア開発と検証の意思決定にも影響を与えています。
 

• 自律システムに対する監視の強化

自律航空機の普及が進むにつれ、その開発と認証に関する規制はより厳格化されるでしょう。機械学習などの支援技術にも制約が課され、開発・認証コストや市場投入までの期間に影響を及ぼす可能性があります。実績のあるソフトウェア開発・テストプロセスを採用している企業では、認証取得における潜在的な障壁を回避し、先行者利益を維持するための準備がより万全になるでしょう。
 

• 小型飛行機の数の劇的な増加

エアタクシーや配送ドローンなどの小型航空機は、対応体制が整っていない業界において劇的な成長が見込まれています。小型航空機に関する既存の安全規制は、大型の商用航空機に対するものと比較して、利用頻度が低くリスクが低いシナリオを反映していました。有人機や自律型の小型航空機の導入が進むにつれて、この状況は変化する可能性が高いでしょう。
そこで、先行者は、要件の変化に合わせて柔軟で拡張性の高い設計アプローチを採用する必要があります。その効果的なアプローチは、商用航空機で実証済みの厳格な設計手法を多く取り入れ、多くの新たな要件の基盤となるものです。
 

• 持続可能性とゼロ排出が設計に与える影響

持続可能性への取り組みには、排出量の削減と航空機の電動化が含まれており、電力の生成と管理のための新しいソフトウェアシステムが必要です。システムの決定においては、航空機のサイズ、重量、電力要件の削減が重視されますが、複雑性が増す可能性があります。
 
たとえば、マルチコアプロセッサを最大限に活用するソフトウェアは、軽量化を実現すると同時に、機能性とシステムの俊敏性を向上させることができます。しかし、マルチコアシステムのソフトウェア開発、テスト、コンプライアンス遵守には、複雑さと時間という新たな課題が伴います。電動垂直離着陸機（eVTOL）などの新技術向けの複雑なソフトウェアも認証取得を困難にする可能性があります。規制や技術が発展するにつれ、自動化ツールに裏付けられた既存の規格は、新技術に伴うリスクを軽減するための確固たる基盤となり得ます。
 

• 接続性の向上がもたらす新たな攻撃ベクトル

航空電子機器システムは、監視、保守、診断に加え、自律航空機で本質的に必要な追加の接続性のために、ますます接続性を高めています。こうした接続性は運用効率の向上につながる一方で、安全性に影響を与えるセキュリティリスクの増大にもつながります。そのため、セキュリティに対する「シフトレフトアプローチ」つまり航空安全性と並行してセキュリティをシステムの設計に組み込むことが極めて重要になります。
 
接続性には脆弱性への対応能力も必要です。新たに発見された脆弱性は、要件が変更されたか新しい要件であることを意味し、システム自体が開発エンジニアによって長期間保守されていないとしても、迅速な対応が求められます。このような状況では、自動化された要件トレーサビリティツールで、必要なものを特定し、影響を受ける機能のみを自動的にリグレッションする機能が、非常に重要になります。
 
これらのトレンドや新機能によって、システムが何を行うかだけでなく、それをどのように行うかも変化する可能性があり、その変化はソフトウェアに依存するものです。航空電子機器ソフトウェアの耐空証明を確実に取得するには、安全性とセキュリティの評価だけでなく、開発プロセスにも注力することが必要です。既存ソフトウェアの再利用により、開発とコンプライアンスのリソースを新機能に集中することができますが、複雑なシステムの開発は困難になり、適切な運用も困難になります。これにより、既に困難な次世代ソフトウェアの耐空証明という作業は、さらに困難なものになっています。同時に、ソフトウェア開発者の不足が深刻化しているため、航空電子工学や航空宇宙業界のリーダーは、継続的な製品リリースのスケジュール遵守と既存システムの保守・更新のために、新たな効率化策を模索せざるを得なくなっています。認証にかかるコスト、時間、リスクの削減を目的とした取り組みは、ビジネスリーダーにとって不可欠な活動となっています。

認証取得に要するコスト、時間、リスクの削減を目的とした取り組みは、ビジネスリーダーにとって不可欠な活動となっています。

ソフトウェア開発や検証ツールに関する意思決定は、これまで個々の開発チーム内で行われてきました。しかし、今日の複雑な規制環境と競争機会の短期化により、これらの選択はより広範な影響を及ぼすようになりました。認証取得に要するコスト、時間、リスクの削減を目的とした取り組みは、ビジネスリーダーにとって不可欠な活動となっています。ビジネスへの影響を理解することで、経営陣はより多くの情報に基づいた意思決定を行うことができます。

ますます複雑化する民間航空規制の状況

耐空性とは、承認された航空機の使用および運用制限に従って、安全に飛行を開始、維持、終了できることを検証し、文書化した航空システム構成の能力です。FAA [2]、EASA [3]、カナダ運輸省[4] などの国際機関は、航空安全基準、ガイダンス、法律の起草に責任を負っています。
 
図1は、主要な関連規格間の関係を示しています。これは、わかりやすくするため単純にしたもので、たとえば、統合モジュラーアビオニクス（IMA integrated modular avionics）とマルチコアプロセッサに関する文書は明らかにハードウェアに関連しますが、それは示されていません。この図はFAA文書の命名法のみを示していますが、EASAの同等の文書にも同様に適用できます。
 

図1：民間航空規格の概要とそれらの関係
 
規制環境も、特にソフトウェア分野において、かつてないほど急速に進化しています。数十年にわたって制定されてきた規格は、現在では更新頻度が大幅に増加しており、複数の新規格が最近発表されたり、議論されたりしています。その結果、これらの規格への準拠にかかるコスト、時間、リスクは、新型航空機の成功を左右する重要な要素となります（図2）。
 

図2：ソフトウェアに関連する民間航空規格の数と変更率はともに増加しています

民間航空機開発のライフサイクル

航空宇宙推奨基準ARP4754A[5]は、航空機の認証全てを網羅する包括的な文書です。航空機システムの認証を支援する開発プロセスを詳述し、「システム要件からシステム検証まで、航空機開発サイクル全体」を扱っています。ARP4761[6]は、ARP4754に基づく認証を支援するために設計されており、民間航空機の認証における安全性評価に関連するガイドラインと手法を含みます。

航空機搭載ソフトウェア規制

DO-178C [7]は、すべての商用ソフトウェアベースの民間航空システムを承認するために、認証機関が参照する主要な文書です。DO-178Cは、モデルベース開発(DO-331[9] )、オブジェクト指向技術(DO-332 [10] )、形式手法(DO-333[11] )など、ますます普及している開発アプローチの使用をサポートする文書によって補完されて、DO-178B [8]に取って代わりました。
 
DO-33xシリーズの4番目の文書であるDO-330 [12]は、ソフトウェアツールの認定を扱っています。これはDO-178Cを補足するものではなく独立した規格であるという点で、他の3つとは異なります。
 
DO-326A [13]は、航空機のセキュリティを扱い、ソフトウェアとハ​​ードウェアの両方に影響を与えます。これはサイバーセキュリティの耐空性認証における唯一の適合基準（AMC：Acceptable Means of Compliance）であり、航空宇宙セキュリティフレームワークの中核文書です。DO-356 [14]はDO-326Aを補足するものであり、開発の各段階で達成すべきセキュリティ目標、耐空性リスク評価プロセス、および必要な証拠資料を詳細に規定しています。
 

アドバイザリーサーキュラーとポジションペーパー

CAST-32A [15]は、認証局ソフトウェアチーム[16]が作成した最後のポジションペーパーです。これは、後継のアドバイザリー文書であるAC 20-193 [17]とAMC 20-193（A(M)C 20-193 [18]と総称されます）が発行された時点で廃止される予定です。
 
CAST-32AとA(M)C 20-193は、マルチコアプロセッサの使用に関連する特有の認証上の課題、特に実行タイミングに関連するリソースの割り当てについて扱っています。
 
もう一つのアドバイザリーサーキュラーであるAC 20-148 [19]は、複数のシステム間で再利用されることを目的としたソフトウェアの認証について扱っています。
 

地上ベースのソフトウェア規制

DO-278A [20]は主に、地上通信、航法、監視、航空交通管制（CNS/ATM）システムのソフトウェアに焦点を当てています。図1からわかるように、商用オフザシェルフ（COTS：Commercial Off-The-Shelf）ソフトウェアの適用に関する追加セクションを除けば、DO-178Cとほぼ同一です。

規制上の課題を克服するのにツールはどのように役立つか

ソフトウェアの検証には通常、計画・開発プロセスの全体と同等以上の時間、労力、そしてリソースが必要です[21]。そのため、テストと認証はコストのかかる作業となります。
 
コンプライアンス遵守のためのシステム開発には、新規システムと製品アップグレードの両方において、開発と検証活動の監査が含まれます。残念ながら、多くのプロジェクトチームは、ソフトウェア開発・検証プロセス自体よりも、個々の監査やマイルストーンの結果に重点を置いています。このような近視眼的なアプローチは、最良の場合でも最適とは言えないソフトウェアを生み出し、多くの場合、ソフトウェアの障害につながります。成功している開発チームは、ソフトウェア開発ライフサイクル全体を扱う大局的なアプローチを採用し、あらゆる段階を通して効果的なコミュニケーションとナレッジトランスファーを確保しています。
 
自動化されたソフトウェア開発・検証ツールの統合スイートへの移行は、これらの取り組みに劇的な効果をもたらします。遠隔地や地理的に分散したチームにとってそれは特に重要です。そのようなチームは、開発、テスト、手直しの過程で情報を集約することが必要ですが、その過程で、手動のプロセスや統合されていないツールでは非効率性やエラーが発生する可能性があるからです。
 
図3は、航空規格全体に共通するテーマである統合プロセスを示しています。DO-178Cの統合プロセスであるソフトウェア構成管理、ソフトウェア品質保証、ソフトウェア検証、および認証リエゾンはすべて、次に示すようにライフサイクル全体にわたります。
 

図3：規制ガイドラインには、継続的な検証と要件のトレーサビリティという共通テーマがあります
 
ソフトウェア構成管理プロセスは、プロジェクトのソフトウェア構成管理計画（SCMP：Software Configuration Management Plan）に詳述されているDO-178Cの変更管理およびベースライン/ストレージの目標を満たします。
 
ソフトウェア品質保証プロセスには、プロジェクトのソフトウェア品質保証計画（SQAP：Software Quality Assurance Plan）に従って、DO-178Cの品質保証目標を満たすための方法の適用と関連記録の作成が含まれます。 
 
トレースデータの作成を含むソフトウェア検証プロセスには、プロジェクトのソフトウェア検証プロセス計画（SVPP：Software Verification Process Plan）に従って、DO-178Cの目標を満たすためのレビュー、分析、テストを使用することが含まれます。
 
認証リエゾンサービスは、システム、安全性、セキュリティ、および電子ハードウェアとソフトウェアに関して、開発組織と認証機関間のインターフェースを提供します。  

コスト、時間、リスク：耐空証明のビジネスへの影響

最終的には開発チームが技術に関する決定を下しますが、ビジネスリーダーには、大局的な視点を適用して、製品の開発と認証に伴うコスト、時間、リスクを管理する機会があります。コスト、時間、リスクを削減する最も明確で実証済みの方法の一つは、開発プロセスのできるだけ早い段階で問題を特定し、対処することです。個々のチームは既存のソフトウェアツールとプロセスに慣れているかもしれませんが、今日の変化の激しい環境では、従来の作業方法はもはや効果的ではありません。
 
コンプライアンス要件の複雑さと量の増加によって、エラーの発生率が高まります。統合された自動化ツールなしでこれらの要件に対処することは、もはや不可能です。開発と認証の時間を短縮するには、異なるグループが協力し並行して作業できる必要があります。グループや製品ライン全体にわたって統合された開発・検証ツールチェーンを使用することで、大きなメリットが得られます。

統合ツールソリューションの商業的メリット

スプレッドシートやスタンドアロンのドキュメント管理システムとは異なり、統合ツールはプロジェクトやチーム全体にわたる完全な可視性と変更影響分析を提供し、より迅速かつ適切な設計上の意思決定を可能にします。理想的な検証ツールセットは、要件トレーサビリティ、変更影響分析、テスト管理、コーディング標準への準拠、コード品質レビュー、コードカバレッジ解析、データフローおよび制御フロー解析、単体テスト/統合テスト/システムテスト（ターゲットテストを含む）、そして認証エビデンスの自動生成など、幅広い機能を提供します。
 
このようなツールは、アジャイルやDO-178Cに示されたVモデルなど、あらゆる構造化ライフサイクルモデルに適合します。また、継続的インテグレーション（CI）ワークフローにも適しています。検証ツールはCIワークフローの重要な部分であり、チームは開発プロセス全体を通して同じツールを使用することで、迅速で反復的なソフトウェア開発、検証、そしてデプロイメントを実現できます。CIを適用することで、開発者はフロントエンド統合の一環として静的解析と単体テストを実行し、他のコードベースとマージされる前であっても、コードが意図したとおりに動作していることを確認できます。
 
航空電子機器システムにおけるサイバーセキュリティは、安全性に深刻な影響を与えるムービングターゲットとなっており、ビジネスリスクと不確実性の大きな要因となっています。サイバー攻撃を阻止するための推奨戦略は、開発中に脆弱性を最小限に抑えるようセキュリティを設計に組み込むことです。そして完成したソフトウェアをテストすることで、製品が市場に投入される前に、そのアプローチの有効性を証明することができます。市場に投入された後は、新たに露呈した脆弱性を迅速かつ安全に対処する戦略が重要になります。
 
この課題に対処するため、多くのチームが、コストとリスクを削減して効率を向上させるCI/CDアプローチDevSecOps（開発・セキュリティ・運用の統合）に移行しています。ソフトウェア完成後にセキュリティチームに引き継ぐ従来の方法とは異なり、この「シフトレフト」により、ソフトウェア開発チームとセキュリティチームが効率的かつ費用対効果の高い方法で並行して作業を進めることができます。柔軟でカスタマイズ可能なソフトウェアツールは、リスクレベルや必要な緩和策の厳しさに容易に適応し、要件トレーサビリティツールは、何年も変更されていないシステムであっても、侵害を受けた脆弱性への迅速な対応を可能にします。
 
安全性とセキュリティの両方に対応するというこの要件は、検証が特定のニーズに合わせて拡張可能であることが重要である理由を示しています。たとえば、ツールはDO-178CとDO 326Aの認証を並行して取得する必要があるソフトウェアの開発と検証をサポートする必要があります（図4）。この図では、DO-326Aで規定されているセキュリティプロセスが、ARP4754Aで規定されている航空機開発プロセスと整合されており、両方の規格を満たすために開発者がどのように安全性とセキュリティのハイブリッドなプロセスに従えるかが示されています。複数の規格への準拠を順に達成しようとすると、開発にかかる時間とコストが増加し、コストのかかるリグレッションと修正のサイクルを含んだ不要な手戻りが発生する可能性が高くなります。
 

図4：航空機開発プロセスにおけるセキュリティプロセスとソフトウェア開発プロセス[22]
 
包括的な自動化のサポートがあっても、耐空性規制への対応は困難な作業となる可能性があります。LDRAは認証および規制に関するサポートを提供しており、認証コストが抑えられるという確信が得られます。米国では、FAA航空機認証局米国事務所（ACO：Aircraft Certification Offices US）や国際的なパートナーとの連携経験を持つチームによってサービスが提供される必要があります。包括的な監査サポートに加えて、トレーニング、メンタリング、ライフサイクルデータ生成を迅速化・強化するためのコンプライアンス成果物の作成などが含まれる場合があります。
 
ソフトウェア開発は、プロジェクトの対象となるハードウェアが利用可能になる前、また完全に仕様が確定する前から始まることがよくあります。これは、頻繁なアップグレードを念頭に開発される小型航空機では、しばしば深刻化する問題です。このような状況では通常ハードウェアシミュレータが導入されますが、設計保証レベルの高いクリティカルシステムでは、最終的には実際のターゲットでの検証が必要です。したがって、検証ツールには、シミュレーションとターゲットテストの両方をサポートできる柔軟性が必要です。
 
DO-178C DAL Aに準拠して開発される高度なクリティカルソフトウェアでは、アプリケーションによって実行されるオブジェクトコードが開発者の要件と意図を正しく反映していることを検証する必要があります。ソフトウェアの重要度に応じて異なるツールチェーンを使用すると、認証にさらなる遅延が生じる可能性があります。ソースコードからオブジェクトコードまでのトレーサビリティを実証でき、あらゆるレベルの検証で使用できる単一の柔軟なツールスイートによって、チームは追加の学習曲線なしで、特定されたリスクレベルに迅速かつ効率的に適応することができます。
 
多くの技術リーダーは 、モデルベースソフトウェア開発やオブジェクト指向分析設計などの新しいアプローチを取り入れています。これらは開発期間の短縮を可能にしますが、新たに抽象化レイヤーを入れることは、エラーを防ぐためにテストが極めて重要になることを意味します。検証ツールは、ホストの開発プラットフォーム上または実際のターゲットハードウェア上のいずれかで、仮想プロトタイピングとテストを迅速かつ反復的に実行できるようにする必要があります。これにより、抽象化のためにエラーの発見が遅れて認証に遅延が生じるのを防ぐことができます。
 
最後に、非常に重要な考慮事項として、ツール認定が挙げられます。 DO-178CレベルCを超える認証には、ソフトウェア検証ツールの認定が必須であり、これにはプロジェクト固有の環境におけるツールの動作検証が含まれます。この認定プロセスに関連するコストを削減するため、ツールプロバイダーは、適切なレベルの保証を必要とするプログラム向けに、ツール認定パッケージと認証サポートサービスを提供しています。航空機認証サービスは、システム、安全性、セキュリティ、電子ハードウェアおよびソフトウェアを網羅しています。

次世代フライトソフトウェアの認証での課題の克服

結局のところ、企業がコスト、市場投入までの時間、リスク要因についてどれだけ綿密な計画を立てていても、変化する環境には予期せぬ障害が潜んでいます。サプライチェーンや人員不足から、サイバーセキュリティの脅威や新たな規制要件まで、その障害は多岐にわたります。
 
航空電子機器や航空宇宙産業界が慎重な姿勢をとるのには、それなりの理由があります。しかし、多くの組織では、こうした慎重さが開発・テストのプロセス、ツール、モデルの変更をためらわせる原因となっています。コンプライアンス達成に必要な追加プロセスとリソースを評価するギャップ分析を行うことで、規格が進化してサイバーセキュリティのような問題が注目され、施行される中でも、経営幹部は開発・テストのプロセスとツールについて適切な見直しを行うことができます。
 
成功している組織は、将来はますます困難になること、そして、懸念事項に対処し、根本的な変更を行うべき時は今であり、将来の重要な製品発売時ではないことを理解しています。柔軟で堅牢かつ拡張性の高い開発プロセスは、困難に対処し、リスクと不確実性を低減する最良の方法です。
 
検証と妥当性確認のあらゆる側面において一貫したユーザーインターフェースを備えた包括的な検証ツールスイートを活用することで、チームはプロセス全体を通してドキュメントと共有知識をしっかりと確保できます。製品開発ライフサイクル全体にわたる関連開発ツールとの統合により、次世代フライトソフトウェアの認証での課題を克服するための基盤が提供されます。
 

図5：LDRAツールによる耐空性基準とガイドラインのサポート

LDRAについて

LDRAは50年にわたり、セーフティクリティカルでセキュリティが重視されるアプリケーションのコード解析とソフトウェアテストを自動化するソフトウェア市場を牽引してきました。LDRAは、お客様と協力してエラーの早期特定と排除、そして業界標準への完全な準拠（図5）を実現するため、静的・動的解析を通じて要件をトレースし、幅広いハードウェアおよびソフトウェアプラットフォームの単体テストと検証につなげています。
 
今日もLDRAは、セーフティ、ミッション、セキュリティ、そしてビジネスクリティカルな市場におけるコード解析とソフトウェアテストを自動化するソフトウェアツールの開発と市場牽引を続けています。お客様重視の認証サービスやコンサルティングサービスと連携することで、LDRAツールは、幅広いハードウェアおよびソフトウェアプラットフォームの静的・動的解析を通じた要件をトレースで、早期のエラー特定と排除を実現します。

文献リスト

1. Aerospace Vehicle Systems Institute (AVSI), “Exponential Growth of System Complexity,” 2023. [Online]. Available: https://savi.avsi.aero/about-savi/savi-motivation/exponential-system-complexity/. [Accessed 13th April 2023].
2. Federal Aviation Administation (FAA), “Federal Aviation Administation (FAA),” [Online]. Available: https:// faa.gov/. [Accessed 3 November 2021].
3. European Union Aviation Safety Agency (EASA), “European Union Aviation Safety Agency (EASA),” 2021. [Online]. Available: https://www.easa.europa.eu/. [Accessed 3 November 2021].
4. Government of Canada, “Transport Canada,” 19 April 2023. [Online]. Available: https://tc.canada.ca/en. [Accessed 28 April 2023].
5. SAE International: S-18 Aircraft and Sys Dev and Safety Assessment Committee, ARP4754A: Guidelines for Development of Civil Aircraft and Systems, SAE International, 2021.
6. SAE International: S-18 Aircraft and Sys Dev and Safety Assessment Committee, ARP4761: Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment, SAE International, 1996.
7. RTCC, DO-178C “Software Considerations in Airborne Systems and Equipment Certification”, RTCA, 2011.
8. RTCA, DO-178B, “Software Considerations in Airborne Systems and Equipment Certification”, RTCA, 1992. [9] RTCA, Inc., RTCA DO-331 Model-Based Development and Verification Supplement to DO-178C and DO278A, Washington DC: RTCA, 2011.
9. RTCA, Inc., RTCA DO-332 Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, Washington DC: RTCA, 2011.
10. RTCA, Inc., RTCA DO-333 Formal Methods Supplement to DO-178C and DO-278A, Washington DC: RTCA, Inc., 2011.
11. RTCA, Inc., RTCA DO-330 Software Tool Qualification Considerations, Washington DC: RTCA, Inc., 2011.
12. RTCA, Inc., DO-326A Airworthiness Security Process Specification, Washington, DC: RTCA, Inc., 2014.
13. RTCA, Inc., RTCA DO-356 Airworthiness Security Methods and Considerations, Washington DC: RTCA, Inc., 2018.
14. Certification Authorities Software Team (CAST), Position Paper CAST-32A - Multicore processors, CAST, 2016.
15. Federal Aviation Administration (FAA), “Certification Authorities Software Team (CAST),” 18 August 2020.
16. [Online]. Available: faa.gov/aircraft/air_cert/design_approvals/air_software/cast/. [Accessed 11 November 2021].
17. EASA, “AMC 20-193 Use of multi-core processors,” 2022. [Online]. Available: https://www.easa.europa.eu/ sites/default/files/dfu/annex_i_to_ed_decision_2022-001-r_amc_20-193_use_of_multi-core_processors_ pdf. [Accessed 18th January 2023].
18. Wolfe, “EASA and FAA to Issue Further Guidance on Multicore Certification This Year,” 28 February 2020. [Online]. Available: https://www.aviationtoday.com/2020/02/28/easa-and-faa-to-issue-further-guidanceon-multicore-certification-this-year/. [Accessed 4 November 2021].
19. Federal Aviation Administration, “AC 20-148 - Reusable Software Components Document Information,” 7 December 2004. [Online]. Available: https://www.faa.gov/regulations_policies/advisory_circulars/index. cfm/go/document.information/documentID/22207. [Accessed 22 September 2021].
20. RTCA, Inc., DO-278A, “Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems, Washington DC: RTCA, Inc., 2011.
21. P. Brat, “Reducing V&V cost of flight critical systems: myth or reality?,” in SciTech forum, Grapevine, Texas, 2017.
22. Torens, “Safety versus Security in Aviation, Comparing DO-178C with Security Standards,” in AIAA Scitech 2020 Forum, Orlando, FL, 2020.