発表日: 2019年02月11日 |
Dr. Andreas Himmler, Business Development Manager – Aerospace, dSPACE GmbH
テストとは、エンジニアリングチームが製品の機能、信頼性、操作安全性を評価するために実行する基本的な試験です。航空宇宙産業や自動車メーカー、サプライヤなど、多くの業界では、テストプロセスにおいてさまざまなベンダー固有のツールを組み合わせて使用しています。これらのツールは開発者が高い生産性を実現するうえで確かに役立ってはいますが、その一方でワークロードに影響を及ぼし得る制限も内包しています。最も大きな難点の1つは、ツールの使用言語が異なるためにツール間でテストケースを交換するのが難しかったり、場合によってはできなかったりすることです。
部門間、さらには企業やサプライヤ間において、開発ステージを問わずにテストケースを自由に交換できればどれほど素晴らしいでしょうか。これが可能になれば、無駄な労力、特にテスト用に生成しなければならないコードを確実に減らせるだけでなく、テストの実装にかかる全体コストも削減できます。航空機システムなど、操作上の安全性が求められる大規模かつ複雑なシステムでは、このような自由度は大きな効果をもたらします。
この問題を克服する1つの方法は、標準化です。テストベンチと自動化ツール間のインターフェースを標準化し、テストケースの交換形式を標準化すれば、さまざまなベンダーのツールチェーンでテストケースを容易に再利用できるようになるだけでなく、部門間、さらには企業やサプライヤ間でテストケースを交換できるようになります。さらに、エンジニアはローカルのツールチェーンを使用して簡単にデバッグを行い、失敗したテストバージョンを独自の慣れ親しんだ環境で検査することもできます。
私は最近、「Interfacing and Interchanging – Reusing Real-Time Tests for Safety-Critical Systems(インターフェース接続と相互変換 - セーフティクリティカルなシステム向けリアルタイムテストの再利用)」という記事をdSPACEの同僚であるRainer Rasche、さらにはビジネスパートナーであるAirbus Operations GmbHのVolker Meyer氏、Bremen Institute of Industrial Technology and Applied Work Science(BIBA)のMarco Franke氏およびKlaus-Dieter Thoben氏と共同執筆しました。これらの課題を追求し、発見したことをここで簡単にご紹介します。
標準化を通じたテストベンチのインターフェース接続とテストケースの相互変換
私たちは、問題の解決につながると思われる2種類のアプローチについて調査しました。1つ目のアプローチは、テスト自動化ツールとテストベンチ間のインターフェース接続を可能にするということです。2つ目のアプローチは、ユーザがテストケースや定義を異なるテスト自動化ツール間で交換できるよう、相互変換を容易にするということです。
この表は求められる機能を示したものです。「x」はインターフェース接続のアプローチと相互変換のアプローチでの機能の利用可能性を示しています。
標準インターフェースを自動テストツールおよびテストベンチ間で使用すると、ユーザはソフトウェアとシミュレーションハードウェアを自由に組み合わせて使用できるようになります。また、ツールやテストベンチを必要に応じて柔軟に切り替えることもできます。これは一般的には2通りの手法、つまり、プロトコルレベルでの標準インターフェースとAPIレベルでの標準インターフェースがあります。シミュレーション目的では、APIレベルでの標準化の方がよく使用されます。
Association for Standardisation of Automation and Measuring Systems(ASAM)は、テスト自動化ツールとテストベンチ間の通信の汎用シミュレータインターフェースとしてXIL APIを開発しました。これにより、ユーザはベンダーや開発ステージに関係なく、要件に応じて自由に製品を選択できます。
この規格の最新バージョンはXIL API 2.0です。XIL APIを使用したテストベンチおよびテスト自動化ツールの優れた相互運用性は、異なるベンダーおよび製品間でのクロステストにおいて実証されています。XIL APIを使用することで、エンドユーザはテストに最適なソフトウェアとハードウェアを組み合わせて使用できるようになります。規格はテクノロジに依存しておらず、必要に応じてJavaやC++,などの他の言語に簡単に拡張できます。
さまざまなマルチベンダーテストシステムを利用している企業では、多くの場合、独自の構文やセマンティクスを使用するさまざまなテストプロシージャ言語が混在しています。これを標準化された交換形式にすることで、ユーザは異なる自動化ツール間においてもテストケースや定義を相互変換できるようになります。
一般的なテストプロシージャ言語としては、Testing and test control notation(TTCN-3)、Automatic Test Mark-up Language(ATML)、XIL内の信号記述定義などがあります。一般的なテストプロシージャ言語では、セットアップ環境をアドレス設定し、障害がテスト対象システムにどのように入り込むかを記述し、可能性のある欠陥状態や予想される結果(特定のパラメータ値の割り当てに関連する結果)を定義しますが、セマンティクスにおいてはつながりはありません。
ロギングなどの特定のテストベンチ関数のセマンティクスはテストプロシージャ言語の外側で定義されています。これが、テストケースの交換が複雑になる要因です。テストベンチ機能の相互変換を可能にするには、テストベンチ固有の実装からセマンティクスを抽出して状態図で表すか、または同様のテストベンチ固有の機能をさまざまなテストベンチ間でマッピングする必要があります。いずれの場合も、あるテストベンチの機能が別のテストベンチで利用可能になるという保証はありません。
相互変換可能なテストプロシージャを作成するには、次の2段階のアプローチが必要です。
この2つの手法の目標は、一方のフォーマットから構文とセマンティクスを抽出し、必要なセマンティクスをカバーする他方の構文にそれを変換することです。
標準インターフェースと相互変換のアプローチ、およびこれらのソリューションの実装方法について詳しくは、技術論文「Interfacing and Interchanging – Reusing Real-Time Tests for Safety-Critical Systems」をダウンロードしてください。この論文において、概念実証が行われています。
最新の技術開発動向をつかんで、イノベーションを加速。
メールマガジンの購読希望・変更/配信停止手続き