Classic コンポーネントと Adaptive コンポーネントをテストするには、テストケースを一つでも実行する前に、その不一致を手作業で調整し、RTE または ARA への依存関係をすべてスタブ化する必要があります。
AUTOSAR は Automotive Open System Architecture の略で、自動車業界におけるソフトウェアの効率、拡張性、再利用性を向上させる標準化されたソフトウェアアーキテクチャフレームワークであり、さまざまな ECU 間で統合および連携する自動車ソフトウェアコンポーネントを開発するためのガイドラインと仕様が含まれています。
AUTOSAR は、モジュール式の多層アプローチを推進することで複雑さを管理し、ソフトウェア機能をハードウェアから分離して、柔軟性と相互運用性を可能にします。標準化されたインターフェースと通信プロトコルにより、自動車システム間の互換性が促進され、車両モデルや世代を超えたソフトウェアの再利用が容易になります。
AUTOSAR Classic と AUTOSAR Adaptive は、自動車ソフトウェアの標準化という同じ包括的な目的を共有していますが、異なる要求に対応しています。
主に、エンジン制御やブレーキシステムなど、決定論的な挙動と低遅延応答を必要とするハードリアルタイム制御システム向けに設計されています。
インフォテインメント、テレマティックス、高度な運転支援システムなどで一般的に見られる高性能コンピューティングシステムをターゲットとし、動的なソフトウェアアップデート、サービス指向の通信、POSIX オペレーティングシステムのサポートを活用します。
AUTOSAR には多くの利点がありますが、Simulink モデルレベルと量産コードレベルの両方でソフトウェアをテストする場合には特有の課題も生じます。
モデルレベルとコードレベルの両方でテストが必要ですが、AUTOSAR インターフェースはコードレベルにのみ定義され、モデルレベルには存在しません。コード生成ツールがこの隔たりを埋めますが、同じ AUTOSAR コンポーネントでも、使用するツールが dSPACE TargetLink か MathWorks Embedded Coder かによってモデルアーキテクチャは大きく異なる場合があります。テストツールには、この対応関係を自動的に認識し、手作業でテストハーネスを用意せずに両方のレベルでテストを実行できることが求められます。
AUTOSAR ソフトウェアコンポーネントまたは Adaptive アプリケーションを量産コードレベル(SIL)でテストするには、コードをコンパイルする必要があります。また、これらのコンポーネントは、一般的な非 AUTOSAR アプリケーション以上に自己完結性が低くなっています。個々のユニットをコンパイルしてテストするには、RTE(Classic)または ARA(Adaptive)への依存関係をスタブ化する必要があります。
BTC Embedded Systems は AUTOSAR コンソーシアムのメンバーであり、長年にわたり同プラットフォームを支援してきた経験を有します。
dSPACE TargetLink と MathWorks Embedded Coder の AUTOSAR Classic/AUTOSAR Adaptive に全面的に対応します。
BTC TestStack は AUTOSAR アーキテクチャを自動的に解析・認識し、対応するテストインターフェースを抽出します。たとえば、「Get」セマンティクスを持つクライアント/サーバー呼び出しは、テストアーキテクチャの入力信号として解釈されます。
モデル要素とコード要素のマッピングを理解するため、テストハーネスを手動で準備しなくても、テストはモデルレベルとコードレベルの両方で実行されます。
コード生成ツールが提供するスタブ実装を使用するか、不足する要素を BTC TestStack が追加することで、すべての外部参照を適切にスタブ化します。
ISO 26262 認証を取得
この証明書は、複数業界の機能安全規格を対象としています。
ISO 26262 に関して、BTC TestStack は最高の Tool Confidence Level(TCL)で認証されており、ASIL D を含むすべての ASIL レベルに有効です。ご要望に応じて証明書とレポートを無償で提供し、お客様側のツール認定作業の大部分を削減します。
実際のエンジニアリング課題をお聞かせください。評価ライセンス、ワークショップ、個別相談のいずれが次のステップに適しているかをご案内します。