アビオニクスソフトウェア開発

アビオニクスソフトウェア開発は、基本標準RTCA \ DO-178Bに基づいています。 プログラマーの直接のルーチンから離れていることを一見したにもかかわらず、彼は開発プロセス全体を説明し、そのようなソフトウェアの要件を提示しています。 それにもかかわらず、この記事では、飛行機やヘリコプターの飛行制御システムや飛行制御システム、着陸システムなどの開発における個人的な経験に基づいて、すべてが実際にどのように起こるかについて説明します。

エントリー

航空機制御システム（ Flight Control System ）の制御と監視のための最新のソリューションは、複雑なハードウェアとソフトウェアの複合体であり、その作業は、おそらく全体として、従業員と開発者のいずれにも知られていません。 これは、第二次世界大戦の原子爆弾の開発に似ています。誰もが自分の仕事の一部をよく知っていますが、なぜ一緒に機能するのかは実際にはわかりません。 しかし、アビオニクスはそのような複雑なシステムの唯一の例ではなく、同じMicrosoft ExcelまたはGNU GCCの複雑さはもちろん同様の問題を引き起こしますが、それでも航空ソフトウェアには微妙な違いがあり、個別に焦点を合わせようとする典型的なソリューションがあります。 開発プロセスの効果的な管理の問題に直面して、管理、コストパラメーターとプロジェクトの品質の最適化に従うことを試み、情報と組織の赤字を作成します。 これは主に、スペシャリストおよび/または航空ソフトウェアの分野でのトレーニングの費用が高いためです。 スタッフと、 多くの場合、大規模なプロジェクトでは、その数は、制御システムだけで約2〜3千人に達します（機体、特に製品の動的モデルと物理的性能は言うまでもありません）。 第二に、コミュニケーションの編成と情報の流れ、開発参加者間の同期、および1つまたは別のレベルを通過する過度に大量のデータの制限。 したがって、このようなシステムの開発では、要件の開発、ハードウェアとソフトウェアの作成、システムの実装とデバッグ、および認証ドキュメントのテストと準備の特別な、慎重に文書化および規制された技術プロセスが承認されました。 それにもかかわらず、プロジェクトの現実と世界の姿に基づいて、プロセスは絶えず修正され改善されています。

開発モデル

重要なシステムを開発するには、エラーの最小の可能性を確保する必要があります（航空電子工学の最高レベルでは、障害の確率は10 ^ -9です）とともに、コードの開発と修正のコストを最小限に抑える必要があります。 システムの複雑さと他の部分（他のソフトウェア、他のハードウェア）との関係により、ウォーターフォールモデルまたはアジャイル開発は最良の選択肢ではない可能性があります。したがって、 V字型開発モデルがそのようなソフトウェアを開発するための基本原則として選択されます。





図1. V字型開発モデル。



まず、このようなモデルを使用すると、各反復ですべてのプロジェクト参加者の同期を確保できます。また、既に蓄積されたデータと既製の方法論を使用する機会を提供します。 このモデルは組織やプロジェクトの種類に依存しないため、プロジェクトの開始時に、V字型モデル（図1）をこのプロジェクトに適合させることができます。 Vモデルを使用すると、アクティビティを個別のステップに分割できます。各ステップには、必要なアクション、手順、推奨事項、アクティビティの詳細な説明が含まれます。 これは、アビオニクスソフトウェアの開発とテストのマルチイテレーションサイクルにとって特に重要です。 実際、ソフトウェア開発を個別のサブサイクルに直接分割できます。 通常、Vモデルはスパイラル開発モデルに一般化されます（図2）。 これにより、開発の各段階でリスクを評価できるようになり、スペシャリストのワークロードを最適に分散できます（従業員の不足と短時間の時間の条件の下で（反復パッケージ、各ベースラインのV字型モデルと同期）。





図2.スパイラルソフトウェア開発テストモデル

設計とドキュメント

各段階を制御し、その後の認証の可能性のために、プロセスは異なるレベルに分割されます。各レベルには独自のドキュメントがあり、それを制御するドキュメントが作成されます（レポート）。 その結果、開発の各段階、すべてのエラーと修正が分類され、文書化されます。 開発の反復を毎回繰り返すことにより、エラーの可能性が減少します。 これらのドキュメントは、会社の内部標準と顧客が提示した要件に基づいて作成されます。





図3.文書と要件の関係



もちろん、すべてはお客様が率いています。お客様は、自分が何を必要としているのかよくわからないことがよくありますが、飛行機を飛ばしたい、あらゆる状況に対応するタキシングおよび調整システムがあり、このシステムが機能することも十分に言えます彼がそれを望んでいる方法、そしてボーナスさえも。 したがって、最初の部分は、顧客の要件を分析し、システムの基本機能を決定することです。これに基づいて、使用される機器の技術的な詳細を含むシステムの一般的な概念とスキームが作成されます。 初期機器仕様とシステム要件を作成します。



システムが作成されるベースが決定されると、ソフトウェア開発計画とその認定（資格計画-認定のソフトウェア側面の計画）に応じて計画が承認されます。 顧客にとって主なことは既製の管理ソフトウェアを入手することですが、並行プロセスはハードウェアの開発であり、ソフトウェア開発では無視できません。 アビオニクスソフトウェア開発は、ハードウェアと非常に密接に関連しています。 ほとんどの場合、ソフトウェアは移植性と埋め込み性がありますが、システムのレイアウトに大きく依存しますが、それについては後で詳しく説明します。





図4.法定文書に従って段階に分割されたV字型モデル

開発

コンセプト

先に進む前に、初期設計は開発プロセス全体に存在する基本原則に基づいており、主なものは「相違点」であり、制御システムの各部分はさまざまなソフトウェアツール（開発ツール、プログラミング言語など）を使用して、さまざまなハードウェアスタッフにさまざまな人々のグループが実装します。 したがって、システムはソフトウェアとハ​​ードウェアに依存しない部分に分割され、開発プロセスは、より高い要件と計画に従って、異なるタスクと異なるレベルでそれぞれ異なるグループの人々によって制御されます。

ハードウェアとソフトウェア

初期設計の結果は、通常、Matlab \ Simulink、Labview環境で実行されるシステムモデルです。 モデルに基づいて、どのハードウェアを使用し、どのハードウェア同士で通信する必要があるかを規制するドキュメントが作成されます。 少なくとも、この手順の結果として、ハードウェアコンポーネント（ハードウェア）とソフトウェアとハ​​ードウェア（ハードウェア-ソフトウェア）の定義という2つのドキュメントが作成されます。



次に、準備、ボードおよび完成したモジュール（コントロールエレクトロニックなど）のエンジニアリングプロセスの段階が始まります。 直接インストール、必要なマイクロコントローラーの配線、超小型回路、周辺機器。必要なソフトウェアが書き込まれます。 ハードウェアと対話するには、ドライバーとフレームワーク層が必要であり、それに基づいてアプリケーションを構築する必要があります。 それでも、多くの場合、プログラマの作業は、必要なドライバー\機能を追加する必要があるときにすでに始まり、ほとんどの場合、HSI（ハードウェアソフトウェアインターフェイス）ドキュメントに基づいて「包括的なライブラリ」を変更します。 そのため、最も一般的な方法は、使用する機器とドライバーの制限までシステム機能を「トリミング」するだけでなく、異常なピン配置や選択したリアルタイムパラメーターの最適化などのキャリブレーション設定を変更することです。





図5.ソフトウェア構成

枠組み

したがって、フレームワークのユニバーサルライブラリには、航空での使用が認定されたデバイス用のすべての種類のドライバーと、認定された標準機能および手順が含まれています。



これは基本的なポイントです。たとえば、最も一般的なstrcmp関数は直接使用できないため、標準に従って書き換えて認定する必要があるためです。 このような認定された標準機能、プロトタイプ、テンプレートのセットは、フレームワーク層で共通です。 この態度は、安全な数学演算（整数プロセッサ、モジュール、ルートなどの高速分数除算など）、およびメモリの操作に特に重要です。 すべてのアルゴリズムは少しですが（少なくともコードのスタイルは）、STLとは異なります。





図6.さまざまな制御および分析インターフェイスを使用できるテストクラスターのアーキテクチャ*



すべての種類のデバイスで使用するために、フレームワークにはDrvHigh <-> DrvLow構造のドライバーセットが含まれています。 ここで、DrvHighパッケージには、デバイスドライバーのすべての種類のインターフェイス（フラッシュ、Eepromメモリ、デジタル-アナログ、アナログ-デジタルコンバーター、リアルタイムクロック、割り込み、CAN、ARINC、LANチップなど）が含まれています。 次に、これらの各ドライバーインターフェイスは、特定のデバイス（1つまたは別のメモリチップ、コンバーターなど）に対して1つ以上のドライバーを使用できます。 最適化の目的で、そのようなドライバーは再構成され、DrvHighレベルなしで直接使用されます。 おそらくこれは最も美しいソリューションではありませんが、アプリケーションプログラムとは異なり、「640kですべての人に十分な」ハードリアルタイム組み込みシステムで作業することは単なる格言ではなく現実です。 高負荷で耐障害性のあるシステムの場合、現実は、マイクロ回路のピーク負荷、データ転送バスの90-100％負荷、チャネル、デバイスの同期、入力パラメーターに応じたフレーム負荷のスケジューリング（フレームスケジューリング）とエラー制御（マルチレベルモニタリングを含む）静的および発振エラーの確認）、およびすべてのソフトウェアとデータオブジェクトを約64〜128kバイトのボリュームに配置します。

プログラミング

必要条件

しかし、ソフトウェア開発サイクルに戻ります。 ハードウェアをインストールして構成すると、ソフトウェアが行うべきこととその方法を説明するソフトウェア要件ド​​キュメントが作成されます。 これは、どのソフトウェアを開発（アプリケーション）するかに基づいたドキュメントです。 これは、テスターの仕事とともに、プログラマの仕事が始まる場所です。

つまり、言い換えれば、アビオニクスソフトウェアプログラマーは、実際にプログラムを作成する対象の全体像を見ることはできませんが、必要な要件と、要件に基づいて作成する必要のあるアーキテクチャで動作します。 プログラマーの要件は次のドキュメントです。

• ソフトウェア設計標準-アプリケーションの全体的なスタイルとアーキテクチャ作成のアプローチを定義する標準。
• プログラミング標準-コードで記述できるものとスタイルを定義するプログラミング標準。
• ソフトウェア要件文書-ソフトウェア要件。文書化され、その中のさまざまなベースラインおよび反復パッケージに分割されます（高レベルの特定アクション）。

最初のドキュメントに基づいて、開発者は自分の問題を解決する方法を設定します：使用できる技術的手段、結果を入力する場所と場所、および遵守する必要があるルール（規則）とヒント（ガイドライン）です。 簡単に言えば、このドキュメントは開発者のツール（プログラミング言語、開発環境、レポート）を確立します。



2番目のドキュメントに基づいて、開発者はコードをスタイルし、トリックを許可するように設定されています。 たとえば、ハンガリーの表記法、算術演算、コード記述スタイル、およびその複雑さの使用。



また、開発者の作業には、既に述べたように、低レベルの要件（HSI、ICD（インターフェース通信）、データシート（デバイスの動作を説明するドキュメント、デバイスメーカーからのルール（さまざまなチップ））の知識が必要になる場合があります。

プロセス

開発プロセス自体は、次の手順で構成されます。



1. 設計 -設計（UMLおよび/またはモデリングシステムでの設計開発（Ameos、SCADE、Simulinkなどのソフトウェアを使用）-

2. 低レベルの要件 -テスターに​​実装された要件を解決するための機能とアルゴリズムの説明（ブラックボックスモデルを使用：入力と期待される応答の説明）。 つまり 低レベルの仕様。

3. コーディング -コードを直接記述するプロセス（SCADE \ Matlabのように自動コードジェネレーターを使用しない場合は、開発環境（IDE）は任意のOSで使用できるため（Eclipse、CodeBlocksを使用しているため、 、他のソリューションは禁止されていません）。

4. デバッグ -デバッグプロセス、またはエラーのない状態（選択したコンパイラのインストールされたパラメーターでのエラー、警告）の状態への処理およびアセンブリのプロセス。

5. 静的チェック -コードアナライザー（xLite、Polyspace、MISRA、QAC）に基づいてコードをチェックおよび修正するプロセス。

6. エンジニアリングテスト -シミュレーター上でソフトウェアを起動および統合するプロセス（つまり、最終バージョンが飛行中にインストールされ、可能であればインターフェースと操作ツール（通常は一連のLabview + Trace32デバッガー）がインストールされるハードウェアプロトタイプ）。 場合によっては、追加のデバイス（センサー、遮断回路、信号発生器、さらにはパイロットのペンなどの制御および監視デバイス）をインストールすることにより、シミュレーターの機能が拡張されます。 非常にまれなケースでは、ほとんどの制御システムでは、これは航空機の実際の実物大のベンチモデルで実行できます。

7. 結果をバージョン管理システムとレポート（IBM Rational ClearCase \ ClearQuest）に入力します。





図7.「電子鳥」スホーイSuperJet 100 *



これらの7つのポイントすべてが1つの反復を構成し、通常は要件の一部に対してのみ実行されます。 機能の変更または既にテストされたコードの修正/修正を行うため、変更要求をコンパイルする必要があります。これに基づいて、ドキュメントとして、既存のレポートドキュメントまたはコードの調整が行われます。通常、これはシステムで行われます。 ベースラインの1つを閉じると、コードまたはドキュメントへの後続の変更は行われませんが、問題レポートに基づいてのみ開始できます。 このような複雑さは、コードおよびドキュメントに対する不正で危険な変更を回避し、対応するアクティビティの前にコードを安定させるために必要です。 変更要求の許可後のコードおよび/または仕様のまさに変更。変更内容を正確に文書化します。

仕様書

各ベースラインの最後に、SDD（Software Description Document）ドキュメントが生成されます。このドキュメントには、アプリケーションの設計に関する情報と、開発者からテスターに​​提供される低レベルの要件が含まれています。 ただし、テスターに​​引き渡す前に、このドキュメントの設計レビューがエラーおよびドキュメントで指定された要件（通常は機能の別の部分を担当する別の開発者によって実行される）でテストされる可能性について実行されます。 これにより、開発者の作業が終了し、次のベースラインに進むか、プロジェクトが完了したら次のプロジェクトに進みます。 もちろんこの場合、開発者はコンサルタントとしてテスターと関係を結び、必要な支援を提供します。



それにもかかわらず、各リンク（システムエンジニア、プログラマ、テスター）は、それぞれの部分への影響と圧力を避けるために分割する必要があることに注意する必要があります。 しかし、もちろん、物議を醸す問題とニュアンスが常にあり、プロセスの明快さにもかかわらず、コメントのタイプミス（たとえば）による反復でプロセスを混乱させないために、主な機能に影響を与えないアジャイル開発モデルがしばしば使用されます。

テスト中

テスターの作業は、ソフトウェア開発の全時間の2 \ 3ではないにしても、ほぼ半分です。 これは骨の折れる長い時間のかかる作業であり、以下が含まれます。

低レベルのテスト

これは、次のもので構成されます：

• コードレビュー -プログラミング標準への準拠、およびコードと要件（SDD）への準拠に関するソースコードのレビュー。
• 低レベルテスト -ユニットテストやユニット統合テスト（Razorcat Tessy +環境およびプロセッサエミュレーター）などの低レベルテスト。 McCabeメトリックと修正条件/決定カバレッジ （NASA MCDC標準を使用）を使用した直接コード要件に基づいたテスト。 ここでは、すべての境界値と、許容可能な条件から抜けるシステムの反応（無効な数学的操作、メモリを伴う操作、ポインター、範囲外などへの反応（堅牢性テスト））がチェックされます。
• レポートドキュメントの作成 （ソフトウェア検証のケースと手順\ソフトウェアユニットと統合検証のケースと手順）。
• VoV （検証の検証）-テストと作成されたドキュメントの正確性を検証する検証検証プロセス。QAR （品質保証レコード）に入力された結果は、次の反復でエラーを修正するために使用されます（別のテスターに​​よって実行されます） ） 当然、バグ追跡システムではQARに加えてすべてのエラーが修正されるため、Iterationは問題を見つけて修正できます。

後続の反復では、デルタテストとデルタレビューの前にプロセスを最小化できます。 プログラム/ドキュメントの変更部分のみをテストするか、以前のテストエラーを修正します。 しかし、これは時間を節約するはずですが、実践が示すように、多くの場合、開発プロセス全体が終わるまでエラーが存在するため、テスターは既成のテストに基づいて毎回システムを完全にテストします。 これは、高い時間コストと、多くの場合コード/テストの変更の割合の増加を除き、回帰テストと見なすことができます。 ここで、これはテストがシステムと並行してではなく、システムに基づいて作成されているという事実によるものであることを強調します。 ご想像のとおり、このアプローチにより、主な問題はプログラマーの肩にかかっています。プログラマーは、アーキテクチャ、コード、低レベルの仕様の優れたバランスを提供する必要があります。 並列開発は、エラーの原因となっている関数と変数までエラーを追跡できる必要があるため、ほとんど不可能です。 テストだけでなく、要件のレベルでも。 これは重いマイナスのように見えますが、彼らは徐々にそのようなモデルからより柔軟なモデルに移行し、テストがコードからではなくアーキテクチャ設計段階から行われるようにブラックボックスプロセスを作成しようとしています。 コードを記述する前に仕様を記述してください。





図8.電子機器および関連システムのテストベンチ*

高レベルのテスト

• 文書レビュー （SWRDレビュー）-システムの要件と仕様、およびハードウェアとソフトウェアのコンプライアンス（ICD、HSI）の観点からのエラーとテスト容易性に関する文書のレビュー。
• ハードウェアとソフトウェアのテストは、シミュレータで高レベルのテストを作成および実行するプロセスです。これは、自動（スクリプト化）、手動（スクリプト化、ハードウェアのどこかに切り替える必要があり、マルチメータまたはオシロスコープで測定）、ユニットテスト（シミュレータで確認することが不可能な場合、テスト/テストは低レベルのものから削除されます）。 このようなテストは、結果がレポートファイル（ハードウェア/ソフトウェア統合検証のケースと手順）に記録され、プロセス全体が通常自動化されることを除いて、開発者が行うエンジニアリングテストに非常に近い。
• HwSw VoVは、検証検証プロセスであり、テストと作成されたドキュメントの正確性を検証します。結果はQAR（品質保証レコード）に入力され、次の反復でエラーを修正するために使用されます（別のテスターに​​よって実行されます）。

開発の最終段階では、実際にはわずかな頻度で、実際の機器での行為を伴うハードウェアテストが行​​われます。 これは通常、組み立てられた航空機のモデルのベンチテストで発生し、その後、実際の航空機で飛行します。

もちろん、各段階の間に、使用される機器の仕様、すべてのデバイスとドキュメントのバージョン、およびソフトウェア自体と関連ドキュメントの両方を含む「配信パッケージ」が形成されます。 これは専門のマネージャー（パッケージマネージャー）によって行われ、コーディネーター（コーディネーターマネージャー）はさまざまなグループのステータスの調整と監視に関与します。 開発とテストのまさに段階は、内部計画（ロードマップ）によって管理されます。これは、マネージャー（実際のステータス）のレポートドキュメントでもあります。

認証

テストに基づいて、一般的なSVR（ソフトウェア検証レビュー）ドキュメントがコンパイルされ、開発段階のある段階または別の段階でエラー状態が決定されます。 これに基づいて、重要度に応じて、ステージの完了時にドキュメントが完成します（SAS、Software Accomplishment Summary）。 このドキュメントは、開発/処理（SWRD処理を含む）の新しい段階の開始が必要かどうか、または開発を停止し、すべてのドキュメントが認証のために顧客に転送されるかどうかを決定します。 このドキュメントは、通常は製造プロセスに大きな影響を与えることなく、バックグラウンドで各ベースラインに対して継続的に実行される技術管理部門の最終版です。



この時点で、プロジェクト全体の監査と検証が開始され、それに基づいて最後の3つのドキュメントが作成されます。

• 初回配達審査（FDR）-荷物配達書類、
• 最初のフライトレビュー（FFR）-最初のフライトに関するレポート、
• ソフトウェア認定レビュー（SCR）-認定委員会の決定。

当然、これらの段階のいずれかで問題が発生した場合、別の（少なくとも）ソフトウェア処理を開始する状況が非常に可能です。 原則として、豊富なドキュメント（これは約10万から20万ページです）によるこのような認証は、低レベルでのみ選択的にチェックされ、高レベルでは、顧客、認証委員会、テストパイロットの回答に従って、改善のための要件が​​作成されます。 原則として、飛行検査の段階の数は2または3であり、認証-1-2。

おわりに

膨大な作業量については、比較的単純なシステム（タキシングおよび着陸システム）の開発に割り当てられた時間は1.5〜2年、表面制御システム（電動アクチュエータと油圧システム）は5〜6年です。 したがって、平均して、システムは2〜3回の大規模な反復（ベースライン）から、大規模で複雑なシステムの場合は18〜20、フレームワークレイヤーの場合は40以上になります。

報告システムとテストルーチンは非常に複雑で扱いにくいため、アウトソーシングリソースはインドでの仕事に惹かれますが、中国と東ヨーロッパではあまり多くありません。 すべての認証は、原則として、証明書が有効な地域（EASA-ヨーロッパ、FAA-アメリカ）、およびロシアの標準（ロシア）で行われます。 機器は個別に認証されているか、すでに独自の認証を持っている必要があります。そのため、残念ながらまたは幸いなことに、温度、時間、および厳しい動作条件でテストされた比較的「古い」モデルおよびソリューションが航空で使用されています。 莫大な複雑さと需要にもかかわらず、それほど多くの優秀な専門家はいませんし、アメリカやヨーロッパでも電子制御システムは最初の方向にすぎません。もちろん、小さな、しかし一部のエラーを含んでいます...しかし、怖がらないようにセキュリティと復元力のあるアーキテクチャについては、次回説明します。



* Cosateqと共同で準備したテストシステム。