航空電子工学ソフトウェア

アビオニクス ソフトウェアは、航空電子工学で使用される、安全性と信頼性に関する法的義務を伴う組み込みソフトウェアです。アビオニクス ソフトウェアと従来の組み込みソフトウェアの主な違いは、開発プロセスが法律で義務付けられており、安全性のために最適化されていることです。以下で説明するプロセスは、商用ソフトウェアに使用される通常のアドホックプロセスよりもわずかに遅く、コストがかかる (おそらく 15 パーセント) と言われています。ほとんどのソフトウェアは間違いが原因で失敗するため、できるだけ早い段階で間違いを排除することも、比較的安価で信頼性の高いソフトウェア作成方法です。ただし、一部のプロジェクトでは、仕様の間違いが展開まで検出されない場合があります。その時点で、間違いを修正するには非常にコストがかかる可能性があります。

ソフトウェア開発モデルの基本的な考え方は、設計プロセスの各ステップに「成果物」と呼ばれる出力があるというものです。^[1] 成果物の正確性がテストされ、修正されていれば、通常の人為的ミスが危険な問題や高額な問題に発展することはまずありません。ほとんどのメーカー^{[2]はウォーター}フォール モデルに従って設計製品を調整していますが、^{[3]ほとんどすべてのメーカーが以前の作業の修正を明示的に許可しています。その結果、}スパイラル モデルに近いものになることがよくあります。

組み込みソフトウェアの概要については、「組み込みシステムとソフトウェア開発モデル」を参照してください。この記事の残りの部分では、その情報に精通していることを前提とし、商用組み込みシステムと商用開発モデルの違いについて説明します。

ほとんどの航空電子機器メーカーは、重量を増やすことなく付加価値を高める方法としてソフトウェアを捉えているため、航空電子機器システムにおける組み込みソフトウェアの重要性が高まっています。

自動操縦装置を備えた現代の商用航空機のほとんどは、飛行中の特定の段階でパイロットの積極的な介入なしに航空機を飛行させることができる飛行コンピュータと、いわゆる飛行管理システム (FMS) を使用しています。また、空中のパイロットの介入なしに離陸、巡航、着陸できるミサイルやドローンなどの無人機も開発中または生産中です。

これらのシステムの多くでは、障害は許容されません。航空機 (民間または軍用) で実行されるソフトウェアの信頼性は、ほとんどの航空機事故が手動エラーによって発生するという事実によって証明されています。残念ながら、信頼性の高いソフトウェアは必ずしも使いやすく直感的であるわけではなく、ユーザー インターフェイスの設計が不十分であることが、多くの航空宇宙事故や死亡事故の原因となっています。^{[引用が必要]}

安全要件のため、ほとんどの国は航空電子機器を規制するか、少なくとも同盟国グループまたは関税同盟で使用されている標準を採用しています。国際航空開発に最も影響を与える 3 つの規制機関は、米国、EU、ロシアです。

米国では、航空電子機器やその他の航空機部品には、連邦航空規則、輸送機に関する第 25 部、小型飛行機に関する第 23 部、回転翼航空機に関する第 27 部および第 29 部によって義務付けられた安全性と信頼性の基準があります。これらの基準は、通常、製造業者から報酬を受け、FAA によって認定されたFAAの「指定エンジニアリング担当者」によって施行されます。

欧州連合では、IECが安全上重要なシステムに対する「推奨」要件を規定しており、通常、政府によって変更なく採用されています。安全で信頼性の高い航空電子機器には「CE マーク」が付けられています。規制の取り決めは、米国やカナダの火災安全と非常によく似ています。政府は試験所を認定し、試験所は製造された製品と組織の両方を認定します。基本的に、エンジニアリングの監督は政府と製造業者から試験所にアウトソーシングされます。

安全性と信頼性を保証するために、国の規制当局（FAA、CAA、DODなど）はソフトウェア開発標準を要求しています。代表的な標準としては、軍事システム用のMIL-STD-2167、民間航空機用の RTCA DO-178Bとその後継のDO-178Cなどがあります。

このソフトウェアの規制要件は他のソフトウェアに比べて高額になる可能性がありますが、通常は必要な安全性を実現するために必要な最低限の要件です。

航空電子工学ソフトウェアと他の組み込みシステムの主な違いは、実際の標準が商用標準よりもはるかに詳細かつ厳密であることが多く、通常は数百ページに及ぶ文書で説明されていることです。通常、リアルタイム オペレーティング システムで実行されます。

このプロセスは法的に義務付けられているため、ほとんどのプロセスには、仕様書や設計書の番号付​​き段落から正確なコード部分まで要件をトレースするためのドキュメントやソフトウェアがあり、それぞれに正確なテストがあり、最終認証チェックリストにボックスがあります。これは、法的に義務付けられた標準への準拠を証明するためのものです。

代替方法の使用や低い安全レベル要件により、特定のプロジェクトからここで説明するプロセスへの逸脱が発生する可能性があります。

ほぼすべてのソフトウェア開発標準では、仕様、設計、コーディング、テストの実行方法と改善方法を説明しています (ソフトウェア開発モデルを参照)。ただし、航空電子工学ソフトウェア開発標準では、安全性と認証のために開発にいくつかの手順が追加されています。

ヒューマン インターフェイスが重要なプロジェクトでは、通常、プロトタイプが作成されるか、シミュレーションされます。ビデオ テープは通常保持されますが、プロトタイプはテスト後すぐに破棄されます。そうしないと、上級管理職や顧客がシステムが完成したと信じてしまうからです。主な目標は、安全性と使いやすさに影響する可能性のあるヒューマン インターフェイスの問題を見つけることです。

安全性が重要な航空電子機器には通常、危険分析があります。プロジェクトの初期段階では、プロジェクトの主要部分について少なくとも漠然としたアイデアがすでにあります。次に、エンジニアはブロック図の各ブロックを取り上げて、そのブロックで問題が発生する可能性のある点と、それがシステム全体に及ぼす影響を検討します。その後、危険の重大性と確率が推定されます。その後、問題は設計の仕様に反映される要件になります。

軍事暗号セキュリティに関わるプロジェクトには通常、ハザード分析に非常によく似た方法を使用したセキュリティ分析が含まれます。

エンジニアリング仕様が完成したら、すぐにメンテナンス マニュアルの作成を開始できます。メンテナンス マニュアルは修理に不可欠であり、システムを修理できなければ安全ではありません。

ほとんどの規格には、いくつかのレベルがあります。機内エンターテイメント ユニット (空飛ぶテレビ) などの安全性の低い製品では、設置と調整の概略図と手順だけで済む場合があります。ナビゲーション システム、自動操縦装置、エンジンの場合は、手順、検査、装備の指示が何千ページにも及ぶ場合があります。現在 (2003 年)、文書はテキストと画像を含む標準形式で CD-ROM で定期的に配信されています。

文書化に関する要件の中でも奇妙なのは、ほとんどの商業契約で、システム文書が無期限に利用可能であるという保証が求められることです。この保証を提供するための通常の商業的方法は、小さな財団または信託を設立して資金を提供することです。その後、信託はメールボックスを維持し、大学の図書館のレンタルスペース（特別コレクションとして管理）などの安全な場所にコピー（通常はウルトラフィルム）を保管するか、（現在ではまれですが）洞窟や砂漠に埋めます。^[4]

これらは通常、他のソフトウェア開発モデルのものとよく似ています。重要な違いは、要件は通常上記のように追跡されることです。大規模なプロジェクトでは、要件の追跡は非常に大規模で費用のかかるタスクであるため、それを管理するために大規模で高価なコンピューター プログラムが必要になります。

コードが書かれると、通常は、そのコードを最初に書いたのではないプログラマー (または通常は独立して働くプログラマーのグループ) によってレビューされます (これも法的要件の 1 つです)。また、特別な組織が、起こりうる間違いのチェックリストを使用してコード レビューを実施することもよくあります。新しい種類の間違いが見つかると、チェックリストに追加され、コード全体で修正されます。

また、コードは、SPARK (Ada プログラミング言語のサブセット)用の SPARK examinerやC ファミリーのプログラミング言語 (主に C) 用のlintなど、正確性を分析する特別なプログラム (静的コード分析) によって検査されることもよくあります。コンパイラーまたは「lint」などの特別なチェック プログラムは、データのタイプがその操作と互換性があるかどうかをチェックします。また、このようなツールは、有効なプログラミング言語のサブセットとプログラミング スタイルを厳密に使用するために定期的に使用されます。別の一連のプログラムは、ソフトウェア メトリックを測定して、間違いがある可能性のあるコード部分を探します。すべての問題は修正されるか、少なくとも理解され、二重チェックされます。

デジタル フィルタ、グラフィカル ユーザー インターフェイス、慣性航法システムなどの一部のコードは非常によく理解されているため、ソフトウェアを作成するためのソフトウェア ツールが開発されています。このような場合、仕様が開発され、信頼性の高いソフトウェアが自動的に生成されます。

「ユニット テスト」コードは、コード カバレッジを100% にするために、コードのすべての命令を少なくとも 1 回実行するように記述されます。すべての命令が実行されたことを確認するために「カバレッジ」ツールがよく使用され、その後、法的な理由からテスト カバレッジも文書化されます。

このテストは最も強力なテストの 1 つです。プログラム ロジックの詳細なレビューを強制し、ほとんどのコーディング、コンパイラ、および一部の設計エラーを検出します。一部の組織では、ソフトウェア設計をモジュール仕様として使用して、コードを作成する前に単体テストを作成します。単体テスト コードが実行され、すべての問題が修正されます。

コードの一部が利用可能になると、それらはコードのスケルトンに追加され、各インターフェイスが機能することを確認するためにその場でテストされます。通常、電子機器の組み込みテストを最初に完了してから、電子機器のバーンイン テストと無線放射テストを開始する必要があります。

次に、ソフトウェアの最も価値のある機能が統合されます。インテグレーターにとって、おそらくシンプルなメニュー システムから、選択した小さなコードを実行する方法があると非常に便利です。

プログラム マネージャーの中には、最低限の機能が達成された後、時間の経過とともに機能の数が増え、システムが次の日付で提供可能になるように、この統合プロセスを調整しようとする人もいます。

一方、テスト エンジニアは通常、テスト リグの組み立てを開始し、ソフトウェア エンジニアが使用する予備テストをリリースします。ある時点で、テストはエンジニアリング仕様のすべての機能をカバーします。この時点で、航空電子ユニット全体のテストが始まります。受け入れテストの目的は、ユニットが安全かつ確実に動作することを証明することです。

ソフトウェアの最初のテストは、厳しいスケジュールの中で最も達成が難しいテストの 1 つであり、ユニットの無線放射の現実的なテストです。通常、このテストはプロジェクトの早い段階で開始し、電子機器の設計に必要な変更を加える時間を確保する必要があります。ソフトウェアは構造カバレッジ分析の対象にもなり、テストが実行され、コード カバレッジが収集および分析されます。

各ステップでは、ドキュメント、コード、またはテスト レポートのいずれかの成果物が作成されます。ソフトウェアがすべてのテストに合格すると (または安全に販売できるレベルに達すると)、それらは認証レポートにまとめられます。このレポートは文字通り数千ページに及ぶことがあります。完成に向けて努力してきた指定のエンジニアリング担当者が、結果が許容できるかどうかを決定します。許容できる場合は、担当者が署名し、航空電子工学ソフトウェアが認証されます。

• 付録: 航空電子工学における頭字語と略語
• DO-178B
• ソフトウェア開発モデル
• 危険分析
• 10 の力: 安全性が重要なコードを開発するためのルール

• ソフトウェアエンジニアリング協会(SEI)の汎用航空電子工学ソフトウェア仕様