画像
Megumi Yoshinaga
Megumi Yoshinaga
Principal Software Engineer
掲載: 2022年10月14日

車載ソフトウェア開発者のpain point

車載向けソフトウェアは日々肥大化、複雑化しており、品質を担保するための評価工数が増大しています。
その中でもハードウェア上で常に同じ異常状態を再現するのは特に難しく、異常系のソフトウェア処理を評価する際の課題になっています。

RH850 VPF (Virtual Platform)とは?

RH850 VPFは下記の特徴を持つRH850 MCUのシミュレーション環境です。

  • SystemCおよびTLM(モデルI/F標準仕様)に基づくシミュレーション環境
  • 命令セット(精度優先、速度優先選択可)に加え、周辺I/Oモデルをサポート
  • 外界モデル(CANシミュレータなど)と連携し、システム全体のシミュレーションが可能
  • ソフトウェアデバッグ環境としてツールベンダのソフトウェアデバッガと接続可能
  • 対応製品:P1x, C1x, E1x, F1x, E2x, U2A, U2B, U2C

RH850 VPFの主な用途と利点は下記になります。

  • 実MCU利用可能前の早期ソフトウェア開発
    • ソフトウェア開発の前倒しを可能にします。
  • リグレッションテスト
    • 自動テストによる作業の効率化を図ることができます。また、ハードウェア装置によらず、テスト環境のN倍化を容易にします。
  • 仮想ネットワーク検証
    • バス使用率の定量的な検証、車載ネットワークのプロトコルを変更した場合の影響や作業の解析を可能にします。

課題に対するRH850 VPFのソリューション

ハードウェアでは異常状態の再現が難しいという課題に対して、RH850 VPFは以下の考え方で、異常状態を再現しています。

  • エラーを検出するハードウェア動作そのものは再現しない
  • 任意のタイミングで異常状態のレジスタ値とエラー信号を再現する

ハードウェア動作そのものの実装を省略することで、異常状態を再現するVPFを短期間で用意することができます。

ECCを例にRH850のハードウェアとVPFの違いを説明します。
ハードウェアでのECCの動作は下記のとおりです。
masterからメモリ(ECCRAM)への書き込み時にEncoderで誤り訂正符号を作成しECC partに保持します。読み出し時にはDecoderで誤り訂正符号を確認し、誤りを検出したらECM経由でINTCに割り込みを要求します。

画像
Step 1: Write the value into ECC RAM. Step 2: Read the value from ECC RAM. If error is detected, ECC send error to INTC via ECM.

上記のECCをRH850 VPFでは下記のように実現しています。

画像
RH850 VPF ECC diagram

異常系のソフトウェアを検証するためには、ソフトウェアが異常状態に遷移できれば良いので、RH850 VPFとしてはエラー状態を記録するレジスタとエラー通知の機能があれば十分です。したがって、実際にエラーを検出するためのEncoder, Decoder, ECC partの実装は不要になります。

任意のタイミングで異常を通知できるようにするため、RH850 VPFのECCでは下記のAPIをサポートしています。

  • 任意のタイミングでレジスタに任意の値を設定できるAPI
  • 任意のタイミングでエラーを通知するAPI

これらのAPIにより、ソフトウェア検証者は任意のタイミングで異常状態の設定とエラー通知が可能になり、異常状態からのシミュレーションができるようになります。

下記はASTC製VLABでの実現例になります。
コマンドラインからAPIをCallし、レジスタの設定、エラー通知を行います。

画像
rh850_sim - VLAB screen

このようにRH850 VPFではハードウェア動作そのものをサポートするのではなく、ソフトウェア検証に必要な機能は何かという観点でモデル化を考え、異常状態の再現環境を提供しています。

今後もRH850 VPFではシミュレータという特徴を活かし、ハードウェアでは再現が難しいソフトウェア検証環境のサポートを進めていきます。

この記事をシェアする

この記事をシェアする