HILSの動作原理

これまで、HILSとはシミュレーションを実行するもの、というお話をしてきました。しかし、そもそも「シミュレーションをするとは何か?」について触れてきませんでした。

そこで今回は、HILSの中でどのようにしてシミュレーション実行が行われているのかについてご説明します。

blog090608_00シミュレーションの目的は、実ハードウェアの動作を模擬する事でした。「模擬する」を言いかえると、「ハードウェアがどのような時間変化をするのか、計算する」となります。

たとえば、クルマが斜面にあるとします。ブレーキを外してギアをニュートラルにすると、クルマは勝手に坂を下り始めます。その時、このクルマは5秒後にどうなっているでしょうか?10秒後はどうでしょう?30秒後には?こういった疑問に答える事が、ハードウェアを模擬する事と言えます。

ハードウェアがどのような時間変化をするのか、計算する」を、もう少し丁寧に見て行きましょう。

ここでステップサイズを1ミリ秒としたとします。その時に、次のような計算をします。

時間=0ミリ秒の状態 を元に 時間=1ミリ秒の状態を計算する
時間=1ミリ秒の状態 を元に 時間=2ミリ秒の状態を計算する
時間=2ミリ秒の状態 を元に 時間=3ミリ秒の状態を計算する
(以後、くりかえし)

これはすなわち、時間=0ミリ秒の時の状態、時間=1ミリ秒の時の状態、・・・と、あらゆる時間におけるシステムの状態をすべて求める事と言えます。あらゆる時間における状態を、上記のようにステップバイステップで計算していく訳です。

今回は、こういった処理がHILSの中で実行されている様子について、少しだけ詳しくご説明します。

シミュレーション実行

HILSの中では、ハードウェアが模擬されています。ハードウェアには、現在の位置、現在のスピードなど、いくつかの「状態量」があります。これらの状態量は、HILSの中にも変数として存在しています。

blog090608_01

HILSの中では、「現在の状態を元に、次の時間の状態を求める」ための演算が、くりかえし行われています。たとえばステップサイズ=1ミリ秒であれば、時間=123ミリ秒の状態を元に、時間=124ミリ秒における状態を求め、さらにそれを・・・といった具合です。

blog090608_02

この「ステップ毎の演算」は、Cコードで出来ています。このCコードは、Simulinkモデルから自動生成されたものです。

MATLABに「Real-Time Workshop」というオプション製品があります。この製品を使用すると、Simulinkモデルに記述された微分方程式を元に、「ステップ毎の演算」を自動生成できるのです。

さて、ここまではCコードで「ハードウェアの状態量を更新する」話しかしませんでした。しかし、HILSはECUと接続して初めて役に立つものです。ですから、ステップ毎の処理には、「内部状態の更新」だけではなく、「I/O処理」も含まれます。

(I/O処理をどうやって実現するのかは、HILSベンダー毎に方法が違います。基本的には、Real-Time Workshopが出力したCコード内から、HILSベンダーが用意したI/O処理ライブラリを呼び出す形になります)

blog090608_03

I/O処理がからんだ場合、「ステップ毎の演算」は上図のようになります。

ECUからの入力、ECUへの出力ともに、デジタルI/OやアナログI/O、CANやLINなどを使用します。

HILSは毎回、現在の内部状態、および現在の「ECUからの入力値」を読み取って、それを元に演算します。

演算結果から、「次回のステップにおける内部状態」および「今回のステップにおけるECUへの出力値」が決まります。

blog090608_04この演算を、ステップサイズ毎に実行します。すると、ECUからは、あたかも実ハードウェアが存在しているかのように見えます。

ポイントは、ステップサイズが1ミリ秒であれば、きっかり1ミリ秒ごとに1回ずつ演算をする事です。速すぎても遅すぎてもいけません。きっかり時間通りという事が重要です。

この「きっかり時間通り」を測るのには、CPU時間などを使用する場合もありますし、別途タイマーボードを搭載して、そのタイマーを使用してタイミングを計る場合もあります。使用するものによって、HILSの「きっかり時間通り」に行う能力が違ってきます。1ミリ秒程度であればソフト的なタイマーで十分ですが、100マイクロ秒を切るようなステップサイズを使用する場合には、タイマーボードがないと厳しいように思います。

まとめますと、

  • HILSの中では、きっかりステップサイズ毎に、1回ずつ演算が行われている。
  • その演算によって、実ハードウェアの時間経過が模擬されている

となります。

(余談)I/O処理タイミング

するどい方は、ハードウェア入力、ハードウェア出力のタイミングがどうなっているのか気になった事でしょう。特に、「ステップ毎の演算」で「今回のステップにおけるECUへの出力値」を決めるという所が引っ掛かったのではないでしょうか。

blog090608_06

HILSの中では、Real-Time Workshopによって自動生成されたCコードが走っているのでした。そしてそのCコードでは、状態の更新と、I/O処理が行われていました。

C言語とは、記述された命令を頭から順番に実行するものです。ですから、数値演算、I/O処理が、それぞれ順番にならべられていて、その時が来れば実行されます。その正確なタイミングは、CPUの演算能力に依存しているため、これといった時間は決まっていません。

これを見て、気持ち悪いな、と感じられた方もいるでしょう。しかし、実際のところ、1ステップ分くらいI/Oがずれても大きな問題となるケースはありません。ECUの更新周期が1ミリ秒であれば、HILSの更新周期を倍の500マイクロ秒あたりに設定してやれば、特に悩む必要もないでしょう。

blog090608_07

しかし、用途によってはどうしても気になる場合があります。その場合には、ステップの頭で、先にECUからの入力を実施してしまう事も出来ます。そうする事によって、ECUから入力するタイミングを一定に保つ事ができます。(こういった機能があるかどうかは、HILSによってまちまちです。)

しかし、ECUへの出力はどうにもなりません。「ステップ毎の演算」では、ECUへの出力値も計算します。このECUへの出力値が本来あるべき場所は、実は今回のステップの頭なのです。つまり、入力と出力は同時に行われる必要があります。

実ハードウェアの動作は、演算によって決まるのではありません。これは物理現象によって決まるものです。したがって、入力と出力のタイミングにズレはありません。

一方、HILSでは、ハードウェアの振る舞いを演算によって決定します。そのため、ECUへの出力値が確定するまでには、どうしても一定時間がかかってしまいます。これについてはあきらめるしかありません。

たとえば、「次のステップにおける状態量」を計算したあと、すぐさま「次のステップにおけるECUへの出力値」を計算するようにしておいたらどうでしょう。そうすれば、次のステップの頭で「ECUへの出力」を更新できるはずです。しかしこれには落とし穴があります。「今回のステップにおける出力値」を決定するには、「今回のステップにおける入力値」と「今回のステップにおける状態量」の両方が必要です。どうしても、「入力の処理」→「出力の処理」の順番になります。これは覆せません。そういったわけで、基本的にはどうにもならないのです。

しかし、どうしてもそれが気に入らない場合もあるでしょう。そういった場合には、「ステップの頭から、何マイクロ秒後にECUへの出力値を更新する」といった機能を持っているHILSもあります。もちろん、ECUへの出力値は前回のステップで決定しておかないといけません。しかし、そういうものとしてモデルを組めば良いだけです。そうすれば、ECUへの出力タイミングを任意に決定する事ができます。ただし、これはとても特殊な例です。ふつうは、ここまで考える必要はないでしょう。

(余談)ハードリアルタイムとソフトリアルタイム

リアルタイムとは、時間通りに実行するという意味でした。

もう少し詳しく見てみると、リアルタイムは、ハードリアルタイムソフトリアルタイムに分類できます。ここでいうハード、ソフトとは、ハードウェア、ソフトウェアの区別ではありません。「厳しい」と「ゆるやかな」という意味の違いです。

blog090608_04リアルタイム処理を行う場合には、ステップサイズ毎に処理を実行します。処理が終了したら、次の時間が来るまで待機します。

blog090608_05しかし、処理にとても時間がかかって、間に合わなかった場合はどうでしょう。

ハードリアルタイムでは、こういった遅れは許されません。ハードリアルタイムでは、「必ず時間内に処理を終える事」が必須なのです。上図のように処理が間に合わない事はオーバーランと呼ばれます。オーバーランをまったく許さないのか、多少の事には目をつぶるのかは、アプリケーション次第です。

たとえば心臓ペースメーカーで、「たまたま心臓動かすのを忘れてしまった!」などという事は絶対に許されません。「しょうがないから後で1回余分に心臓を動かすか」などの判断はもってのほかです。必ず、決められた時間毎に処理を行う必要があります。

ソフトリアルタイムでは、こういった遅れを許します。遅れてしまったものは仕方がないので、あとで遅れを取り戻そうと考えます。帳尻さえあっていればいいのです。ソフトリアルタイムでは、「平均実行回数」が重要です。

たとえばネットワークの帯域保障をする場合、「パケットを送るのが少し遅れてしまったから、あとで多めに送っておいて、平均値を確保しよう」という考え方も許されるでしょう。人間の体感では、多少遅れたり速くなったりしてもあまり分かりません。平均的にスピードが保障されていれば十分です。

ひとくちに「リアルタイムシステム」と言った場合でも、ハードリアルタイムの場合もあればソフトリアルタイムの場合もあります。それは分野によって異なります。

制御系の場合、タイミング的にシビアな場合がおおいため、リアルタイムと言えばハードリアルタイムの事を指す事が多いようです。

一方、IT系ではリアルタイムと行った時にソフトリアルタイムの事を指している場合が多いようです。

HILSはもちろん、ハードリアルタイムです。

一方、SILSの場合にはソフトリアルタイムもありです。人間を相手にしているわけですから、人間の目から見てだいたいリアルタイムであればとりあえず十分です。

たとえば、OpenPLATEには、Simulinkモデルをソフトリアルタイム化する機能があります。OpenPLATEの目的は、Simulinkモデルの妥当性を人間の目からみて検討する事です。人間の目から見て妥当かどうかを判断するのであれば、ソフトリアルタイムで十分です。ハードリアルタイムを実現するにはどうしてもリアルタイムOSが必要になりますが、ソフトリアルタイムであればWindowsで十分です。そういった意味で、お手軽リアルタイムと言えましょう。

次回

次回は、HILS構築上の注意点についてご説明します。