航空宇宙産業および防衛産業におけるネットワーク化された組込みシステム

航空宇宙産業および防衛産業におけるネットワーク化された組込みシステムの検証と妥当性確認

作成者：Joe Cassar、チームリーダー、dSPACE Inc.

機体、衛星、およびその他の航空宇宙機器に存在するシステムネットワークには、長い間、複数のコンポーネントとシステムとの間の高機能なシリアル通信が含まれていました。これらのシステムは、簡単なピアツーピアのシリアル化されたやり取りからスタートし、はるかに複雑化および高速化したマルチポイントネットワークへと発展しました。

アビオニクスのOEMメーカーおよびサプライヤは、組込みソフトウェアの妥当性を確認できるテストシステムを必要としています。多くの場合、これらのテストシステムには、LRUやFADECなどのアビオニクスコンポーネントだけでなく制御対象システムのシミュレーションも含まれています。そのようなテストシステムの多くはクローズドループのリアルタイムシステムであり、HIL（Hardware-in-the-Loop）システムと呼ばれています。

組込みソフトウェアの妥当性を確認するためには、物理的に機体上に存在するさまざまな通信ネットワークインターフェースのエミュレーションが必要となります。単一のテスト対象ユニット（UUT）用のHILシステムでは、特定の通信ネットワークに参加する制御エレクトロニクスやセンサなどの、テスト時には実在しないコンポーネントもエミュレートできなければなりません。このようなシナリオでは、ソフトウェアのテストの際に通信バス（ARINC 429など）をシミュレートできる機能が極めて重要です。この機能により、エンジニアは実際のセンサやアクチュエータのインターフェースを入手していない状態でも、UUTによって幅広いテストを実行することができます。また、一般的には最小限の物理コンポーネントだけでUUTソフトウェアの妥当性確認をほぼ完全に行うことができます。

場合によっては、物理コンポーネントのテストに加えて、追加のテストベンチを構築して、複数のコンポーネントの妥当性を確認したり、これらのコンポーネント間の実際の相互作用を同時にテストできるようにすることが望ましいケースもあります。また、このシナリオでは、単一のUUTと追加のUUT間の通信を切り離して制御することにより、通信の大部分を基本的には維持できるようにしながら、欠陥条件を挿入して特定の部分のペイロードデータを操作できるようにすることも重要になります。これは、ソフトウェアのシステムレベルの実装の妥当性を確認するうえで鍵となります。なぜなら、存在しないコンポーネントから動的なトラフィックをエミュレートするのは困難な場合が多いものの、UUT間の相互作用を同時にテストできるためです。

そのようなテスト条件を容易に実現できるようにするには、常に安定したエミュレーションを実行できるテスト機器が必要であり、多くの場合、安定性に優れたリアルタイムオペレーティングシステム（RTOS）を搭載した組込みシステムの利用が不可欠になります。QNXは、常に安定したパフォーマンスを実現するために使用する一般的な商用RTOSの1つです。ただし、安定性を保証するのに必要なのはRTOSだけではありません。RTOSを実行する中央の組込みシステムが利用する周辺機器が安定性の原則に違反しないことも重要です。

このため、システム全体の設計が適切であることが極めて重要となります。この点において、複数のベンダーによる市販部品では不確実性が増すと言えます。これは、全体として適切に検査されていない状態の複数のハードウェアベンダーによる市販コンポーネントを使用して自作システムを構築する際によく見落とされていますが、重要な基準です。

これらのシステムを統合する担当者の大半は、これらのサードパーティ製アイテムが期待通りに動作することを保証しなければなりません。バスシミュレーションに使用されるインターフェースカードの多くは、さまざまなタイプのテストアプリケーションでの使用を目的としており、PCIまたはPCI Expressバックプレーン全体のバッファ付きデータメモリを用いてデータをリアルタイムで再生する能力を持っています。

たとえば、エンジンやターボファンの動的なプラントモデルのシミュレーションを伴うリアルタイムテストアプリケーションにおいては、バスシミュレーションで使用するインターフェースカードおよびRTOS環境で動的モデルを実行するPCのメインCPU間で、離散的なタイムステップで同期的にデータをやり取りできることが必要です。このような用途では、メッセージ転送のフレームレートだけでなく、バスへの負荷も考慮しなければなりません。

MIL-STD-1553通信バスは、16または32マイクロ秒程度の遅いメジャーフレーム時間周期で動作し、バス負荷は60%～70%に達する可能性があります。つまり、コアCPUと周辺のバスシミュレーションカードとの間では膨大な量のデータがやり取りされています。これらの要件を勘案すると、リアルタイムシステム向けの統合的なソリューションにより、中核的なリアルタイムシミュレーションおよびインターフェース周辺機器間の相互運用性を確保することが極めて重要と言えます。dSPACE SCALEXIOなどの十分に統合された専用ターンキーHILシステムは、ネットワーク化された組込みシステムにおけるあらゆるテスト要件に対応しており、シミュレーションを実行するのに十分な処理能力を持っているだけでなく、センサのエミュレーション、アクチュエータの応答計測、およびネットワークトラフィックのシミュレーションに適した高度な電子インターフェースも提供しています。

歴史的に、民間機に採用されている主なネットワークインターフェースはARINC 429であり、これはポイントツーポイント通信として実装されています。ARINC 429のトランシーバはラベルフィールドとデータフィールドで構成される32ビットフレームでデータを送信し、そのデータ専用のアプリケーションはラベルフィールドによって識別されます。これらのラベルは、特定の用途ごとにある程度標準化されています。このポイントツーポイント通信の性質により、ARINC 429では多くの場合、バスアーキテクチャ全体をエミュレートする際に多数のチャンネルが必要となります。また、ノード間に欠陥挿入を行う必要があるテストでは、テストシステムに必要なチャンネル数が倍増します。

防衛産業用アビオニクスや衛星では、過去40年にわたってMIL-STD-1553Bプロトコルが主要なネットワークインターフェースとなってきました。このプロトコルには、バスコントローラ（BC）をベースとして最大32のリモートターミナル（RT）が含まれており、バス上のすべてのトランザクションはBCによって特定のRTへのデータ送受信が指示されています。

ARINC 429およびMIL-STD-1553バステクノロジは依然として現役であり、幅広いアプリケーションで使用されています。そのため、テストシステムにおいてもこれらの規格をサポートする必要があります。

一方で、アビオニクスおよび防衛産業用アプリケーションでは現在、より多様なネットワークインターフェースも利用されています。SAE AS6802 Time-Triggered Ethernet、IEEE 1394ベースのSAE AS5643、FlexRayなどのプロトコルでは、それぞれのメッセージに転送専用のタイムスライスを提供することにより、メジャーフレームに沿ったメッセージングの同期スケジューリングというアプローチを同様に実現しています。多くの民間機製造メーカーでは、バックボーンタイプのEthernetネットワークインターフェースに加え、ARINC 825や一般的な車載CANプロトコルをベースとした分散クラスタインターフェースによるバックボーンネットワークの強化を図っています。

また、FORM、SCRAMNet、Fibre Channelなどの分散コントローラ間でのメモリインターフェースの共有も、バスインターフェースに代わる選択肢となっています。つまり、テストシステムにはこれらの幅広いインターフェースを採り入れる必要性が生じています。

テストシステムに関して検討すべきもう1つの重要な要素は、バス設定を実現するためのネットワーク管理メカニズムです。アビオニクス用バスのハードウェアベンダーの多くはGUIを提供していますが、通常はWindowsまたはLinux PC環境において非リアルタイムで使用するように設計されているため、問題が生じることがあります。また、QNXまたは同等のRTOS用のデバイスドライバが提供されない場合もあります。これは、通常の使用事例ではデバイス自体で必要な安定性を確保するよう設計されているためです。これは、単純かつ静的なオープンループやstimulus信号ベースのテストには十分ですが、動的なクローズドループシミュレーションの要件には対応できません。動的な要件では、中核的なリアルタイムシステムとネットワークエミュレーションハードウェアとの間に緊密な連携があることが極めて重要です。また、ネットワーク設定ソフトウェアをPC上で容易に設定でき、リアルタイムシステムを対象にできることも必要です。

リアルタイムシステムのベンダーの多くは、リアルタイムプラントモデルにネットワークトポロジの管理を結び付けるための設定ソフトウェアを提供しています。多くの場合、プラントモデルは数理ソフトウェアパッケージとして定義されており、形式もさまざまです。高度なシミュレーションツールが登場したことにより、物理コンポーネントをグラフィカルにモデリングする手法は過去20年でかなり普及しました。つまり、このモデリングコンテンツをシステムにインポートするための設定ツールを利用できることも、すべてのソフトウェアテストシステムにとって極めて重要です。

また、数値的推進システムシミュレーション（NPSS）モデルなど、業界標準のシミュレーションソフトウェアパッケージにネットワーク設定ツールを連携できることも同様に重要です。しかし、そのようなモデリングパッケージがコンパイルされた形式でしか利用できない場合や、特定のOSサポートが必要な場合、さらには複数のCPUコアでの協調シミュレーションによってモデルを実行する必要があるテストシステムなどの場合には、これらを実現するのは困難な場合があります。

dSPACEのテストソリューションでは、単一のアプリケーションによる複数のオペレーティングシステムのホスティングをサポートしているため、マルチコアプロセッサを搭載した特定の環境下のみで実行されるシミュレーションパッケージに対応することができます。

通信ネットワークの設定は、面倒で時間を要するプロセスです。多くの組織では、ネットワークトポロジの定義に、XMLテクノロジに基づいた複数の形式の設定ファイルを使用しています。メッセージの特定のタイミングやメッセージのエンコードおよびデコード方法に関する情報などといったパラメータの記述には、特定のXMLスキーマが使用されています。この場合、ネットワークトポロジ設定用のファイルパーサを実装するテストシステムであれば、あらかじめ定義された設定を利用することができます。しかし、これらのXMLスキーマは標準化されていないため、バス設定を自動化する場合には通常、カスタムエンジニアリングが必要です。そのため、そうしたネットワーク設定の自動化に対応したオープンAPIがテストシステムに搭載されているかを確認することは重要です。dSPACEのシステムには、ASAM規格に基づいたPython、COM、.NET、HIL APIベースのオープンAPIが用意されています。

最後に、アビオニクスのテストシステムにおいては、テストケースを容易に実装し、テストデータをテストシステム全体で効率的に管理できることが必要です。ASAM AE-HIL-BS-1-3-APIは、テストオートメーションソフトウェアおよびHILテストシステム間のインターフェースを実現するための自動車業界の標準として進化してきました。dSPACE AutomationDeskおよびHILテストシステムは、この規格に準拠しています。

これらのツールではテストケースをグラフィカルに実装することができ、その多くはPythonベースのスクリプトAPIもサポートしています。テストオートメーションツールには、テストフレームワークを定義するためのメカニズムが含まれている必要があります。このフレームワークは、定義したすべてのテストケース、一部のエディタ形式、テスト実行、およびテストデータの結果管理のためのベースとして利用可能である必要があります。また、場合によっては要件管理ツール向けのインターフェースも必要です。

結論としては、ネットワーク化された組込みシステムのソフトウェアの妥当性を確認する場合に使用するHILテストシステムを決定するには、リアルタイムの安定性の基準や関連するネットワークインターフェーステクノロジに関する特別な考慮が必要となります。また、これらのシステムには、数理的に記述されたプラントモデルを高い精度で計算してクローズドループの安定性を確保できることも必要となるだけでなく、中核的なリアルタイムシステムおよびネットワークインターフェースカード間の緊密な連携も実現できる必要があります。さらには、設定を容易に行うことができ、必要に応じてネットワーク記述の成果物を最適な形でインポートできる必要もあります。テストオートメーションやデータ管理の問題にプロセス全体で対処できることも重要です。