GAIO CLUB

HOME ＞ GAIO CLUB ＞ システムシミュレータ実機環境との相違点とソフト検証に必要なHWモデル化手法
2005年08月01日

システムシミュレータ実機環境との相違点とソフト検証に必要なHWモデル化手法

GAIO CLUB 特集
GAIO CLUB【2005/8月号】
ソフト品質改善に注目される組み込みシステムシミュレータ実機環境との相違点とソフト検証に必要なモデル化手法
～ シミュレータ導入に対して抑えるべきポイントとは ～

ガイオが提案するシステムシミュレータは、組み込み開発において多くの導入実績を頂いております。シミュレータは、実機を用いた開発環境では困難なデバッグや検証を行える点で優れていますが、実機とは異なる面もあります。
本特集では、シミュレータ採用の際に、従来の実機開発環境と比較して、抑えておく必要のあるポイントについて説明致します。

目次

組み込みシステムシミュレータの概要

組み込みシステムシミュレータは、実機と同様のハード構成を仮想環境内に構築し、マイコンで動作するソフトウエアやシステム動作の検証を行うためのツールです。

ガイオの「システムシミュレータ」は、組み込みシステムを、マイコン（MPU）とその周辺ハードウエアに分割し、前者をマイコンシミュレータ（ISS: Instruction SetSimulator）、後者を「仮想ハードウエア」と呼ばれる周辺ハードをソフトウエアでモデル化したもので実現します。※下図
組み込みシステムをシミュレータに置き換え
マイコンシミュレータは、ガイオの製品の１つとして提供されるものであり、一方の仮想ハードウエアは、開発する組み込み機器の構成に合わせてその都度モデル化を行います。
いずれも、実際のハードウエアを仮想的なソフトウエアに置き換えたものであるため、実際のハードウエアとは、特に時間的な概念や動作原理が異なる部分があります。

実機とシミュレータとの概念の違い

下図は実際の組み込みハードウエアとシステムシミュレータの動作概念の比較を示したものです。デジタルハードウエアの場合、マイコン以外の周辺ハードウエアは、供給されるマスタークロックに同期してマイコンと同時に並行して動作しています。
これをWindowsの仮想環境上に置き換える場合、マイコンはマイコンシミュレータが動作する1つのスレッドとして、また仮想ハードウエアも別の1つのスレッドとして動作します。

PCにはCPUは1つですから、2つのスレッドが同時に並行して動作することは不可能であり、適当な時間単位で時分割されてお互いが動作することになります。
ガイオのシステムシミュレータでは、マイコンシミュレータで実行される命令単位にお互いのスレッドを切り替えて、同じ経過時間分の処理を交互に繰り返す方法を採っています。総合的に見ると、お互いの実行時間は同じですが、常にどちらかのスレッドが止まって、お互いの時間合わせを行う点が、実際のハードとは異なっています。
ハードウェアとシステムシミュレータの動作概念の比較

最小時間単位に対する相違点

実際のデジタルデバイスの動作は、各々が持つマスタークロック単位に動作が行われるため、動作の最小時間単位はマスタークロックになります。シミュレータでも同様で、最小時間単位はマスタークロックです。

ただし、マイコンと仮想ハードの処理の切換は、命令セットごと行われます。１つの命令実行中に周辺ハードの状態が変わるとしても、この結果は、命令実行後にしか反映することはできません。
インストラクション実行単位に仮想HWと同期
しかしながら、i/oポートや割り込みを介した周辺ハードの制御は、マイコンが命令実行を行った結果によって行われるため、通常の組み込みソフトのデバッグにおいては、命令単位以上の時間精度は必要が無く、問題になることはありません。

MPUのバスにマッピングされたi/oデバイスの時間動作モデル

次に、マイコンと周辺ハードウエアのIFであるi/oポートの動作について考えてみます。通常、i/oポートは、マイコンの持つメモリ空間のアドレスにマッピングされます。マイコン内蔵のi/oポートの場合や、バスにぶら下げたペリフェラルチップが持つレジスタの場合でも、考え方は同じです。

実際のハードウエアでは、i/oポートに書き込みが行われる場合、書き込み自体に時間が掛かります。例えば外部ハードが低速のDRAMの様な構造を持っていた場合、供給されるマスタークロックに沿って、RAS/CAS動作、リフレッシュ動作など経て、書き込みが終了します。この間マイコンはウエイト状態に入っています。

時間概念を無視したアンタイムドモデルで実装

これを仮想ハードウエアとしてモデリングする場合、組み込み開発用のマイコンシミュレータのメモリモデルには、DRAMに配線される信号ラインの概念はありません。

例えば、最も単純なモデルの場合であれば、マイコン上で「move」の様なメモリ書き込みの命令が実行された直後に、「時間ゼロ」で想定した値が外部ハードに書き込まれる動作をします。これは、時間概念を無視した最も抽象度の高いモデリング方法で、「アンタイムド（untimed）」モデルと呼んでいます。

時間のズレだけをモデルに実装

しかしながら、このままでは、仮想ハードへの書き込みが起こるたびに、実際の実行時間とのズレが発生してしまうため、この点は考慮する必要があります。

仮想ハード側のモデリングとしては、DRAMの信号ラインの動作をそのままモデル化するのではなく、書き込み動作を行った結果、どれだけの時間が必要であるのかだけをモデル化して、シミュレータの同期に使用するようにします。要するに、マイコンソフトのデバッグを目的とする場合であれば、マイコンから見た結果が同じになうようにi/oデバイスをモデル化すすだけで良く、実際のハードウエアを詳細にモデル化する必要はないと言うことです。
DRAMを例にとったハードウェアモデリングの考え方

メカ制御など一般の組み込みシステムでの時間の考え方

このような、i/oポートアクセスに掛かる時間単位は、通常「ns」オーダーです。
メカ制御などのシステムにおいて、さらにリアルタイムOSが介在して制御が行われるシステム場合であれば、制御に必要な最小時間制度は「μs」オーダー以上である場合がほとんどです。

ここには3桁以上の差があり、この仮想ハード作成には、i/oポートアクセスの時間精度はほとんど影響しません。すなわち、i/oポートを介した仮想ハードモデルには、時間概念のない「アンタイムド」モデルであっても問題はありません。
外界モデルの時間制度と通信などI/Oの時間制度

i/oデバイスの先にある外界ハードウエアのモデル化について

さらに、i/oデバイスの先のハードウエアのモデル化を考えてみます。わかりやすい例として、シリアル通信を使用して、他のシステムとハンドシェイク（相互通信）する動作を考えてみます。
想定されるハードウエア構成は、下図のようになります。
シリアルを使用したハンドシェイク通信の構成概要
MPUにはシリアル通信用のデバイスが接続されており、シリアル通信に必要なコマンドやデータをセットするためのレジスタがあります。
実際のハードウエアの動作としては、

1. MPUが通信データをレジスタにセットする
2. MPUが通信開始のコマンドをセットして、シリアル動作が開始する
3. 設定されたボーレートで決まる時間で、シリアル信号が通信相手に転送される
4. 通信相手が必要な処理を行った後、シリアル動作でデータを返す
5.データを受けたシリアルデバイスがレジスタにデータをセットした後で、MPUに割り込みを発行する
6. MPUは割り込みハンドラでシリアルデバイスをアクセスしてデータを読み出す

となります。
この中で、3、4のプロセスでは、RS-232C等のシリアル通信方式によって信号がやりとりされますが、マイコンソフトから見た場合、2でコマンドを発行した後、一定時間後に5で割り込みが発生した事だけしか見ることが出来ません。すなわち、ソフトのデバッグには、3、4のプロセスを詳細にモデル化しても意味はなく、2から5までの通信に掛かる時間情報と結果だけが与えられれば、システム動作のデバッグには必要十分となります。

マイコンソフト検証に必要なモデル

このような通信システムのモデル化方法としては、以下のような構造が一般的です。

・シリアルデバイスが持つレジスタの内、マイコンソフトがアクセスするレジスタのみをシリアルデバイスモデルに実装する
・シリアルデバイスのコマンドの内、マイコンの動作シーケンスに関わるものだけに限定する
・シリアル信号のハードウエア動作については、一切モデリングせず、通信に掛かる時間だけをモデル化する・通信相手については、詳細なモデル化は一切行わず、設定したコマンドに対する結果だけを返す単純なモデルにする
・通信開始のコマンドがレジスタに書き込まれたら、その内容に従って、通信相手の反応を取得する（ロジックで実装する場合もあるが、多くは想定されるデータをテーブル化して、これを返すだけにする）
・ 全体の通信に掛かる時間を前もって想定し、その時間後に、割り込みを発行する

このように、実際のハードウエアの動作でなく、検証に必要な動作に抽象化して作成されます。
シリアル通信モデルの抽象化とモデリング

通信データに着目したシステムシミュレータとは

マイコンでの処理内容は、制御機器などでのフィルタ演算などを除けば、外部のハードとのデータのやりとりがほとんどです。RS-232CやRS-422、USB、Etherなど汎用的な通信や独自のシリアル方式など、いずれの場合も、通信速度やハードウエアの規格さえ違いますが、本質的には、コマンドやデータをやりとりするだけです。

システム間の通信のほとんどは、送信したデータに対してその応答を返すハンドシェークのような動作になります。
ならば、シミュレータでの開発環境を構築する際に、通信相手のハードウエア動作をモデリングするよりも、コマンドやデータのやりとりに着目して、与えたコマンドに対する応答を自由に設定できる治具的な仮想ハードウエアの方が、システム機能のデバッグがやり易くなります。
通信コマンドに着目した仮想ハード

単なるコマンド発生装置として外界ハードをモデリング

システムへの適用例として、自動車業界で使用されているCAN（車内LAN規格）を介したECU（マイコンを含むコントローラユニット）の動作を、システムシミュレータで検証する場合を考えて見ましょう。

車は、エンジン、ブレーキ、トランスミッションなど、各機能部分がCANによって結ばれています。例えばトランスミッションECUの場合、エンジンからの回転数、トルク、車速、アクセル開度などの情報がCANを通じて送られてきます。
トランスミッションECUをデバッグする場合、これらの外的な条件やデータが全て揃うまでは、制御ソフトの最初の「初期化ルーチン」さえも通過させることができません。
複雑に連携する車載ECU
しかしながら、これらの条件をそろえるために、全ての外的な要因をハードウエア動作としてモデリングするのは、途方もない工数が掛かります。

このECUデバッグの場合であれば、エンジン、ブレーキなどの各外的な要因は、すべてCANデータを発生するボックスと考え、想定したCANパケットを送信するだけの装置としてモデリングします。これには、汎用的なシーケンサを利用することができます。下図は、シーケンサを利用してCANパケットの送受信のみに着目したシステムシミュレータ構成例です。
シーケンサをCANパケット発生器として使用した車載ECU検証のためのSILS環境例
下図は、ガイオの汎用シーケンサーの画面例です。デバッグを行うMPU側から、「REQ」のコマンドを受け取ると、その下に設定した送信シーケンスが動作し、仮想ハード側がパケットを順番に返答する動作がシミュレートされます。
ガイオの汎用コマンドシーケンサ画面の例

さいごに

このように、組み込みシステムのシミュレーションに必要な周辺ハードウエアのモデリングは、必ずしも実際のハードウエアを忠実に再現する必要はなく、あくまでマイコンソフトのデバッグに必要な条件を整えやすいようにモデリング、あるいは汎用的なツールを利用すれば良いことが、お分かり頂けたと思います。
資料ダウンロード

今すぐ資料ダウンロード！

人気のコラム

最新のコラム