※ 2015年3月に執筆したものを転載
SPILSネタの続きです。
前回、SPILSでscilabからgdbに接続する構成を示しましたが、
以下の構成の方が一般的です。
もう一個別のgdbをgdbサーバーとして起動。
scilab直下のgdbからリモートデバッグする体で接続しています。
gdbサーバーを使用したリモートデバッグは本来、別PCで起動しているプロセスをデバッグするときに使用する機能なのですが、これを別の目的で利用しているものがあります。
それが、
「JTAGデバッガ」
JTAGデバッガは実機プロセッサをJTAG回線経由でソフトウェアデバッグするものです。
世に存在するJTAGデバッガすべてが持ってるわけではないですが、
gdbサーバー機能を備えていることが少なくありません。
となると、前回実施した内容をgdbサーバ経由で行えるということは
こんな構成が実現できることになります。
JTAG経由で実機でつなぐパターンと別にシリアル経由でつないでるパターンも記載していますが、
これは実機側にgdbスタブというgdbとシリアル通信するためのソフトウェアモジュールを搭載してデバッグするパターンの構成です。
最近はJTAGのおかげでこの構成は必要なくなってきたのですが、まぁ一応その構成でも行けますよってことで記載。
この実機に接続した構成、
これは「PILS」です。
つまり、SPILSができてしまえば自然とPILSも実現できてしまうということです。
歴史的背景から言うとSPILSより前にPILSが存在しているので
本当は「PILSができる構成があればSPILSもできる」が正しいのですが、
先人の知恵にあやかってSPILSからのアプローチとしました。
さて、今回のテーマのSPILSの利点なのですが、
コンパイラのバグやら実行速度の話とよく結び付けられます。
しかし、
その程度であれば、前回のテーマで実施したISS単体方式で十分です。
わざわざ数式シミュレータと接続する意味はありません。
というわけで、個人的にはSPILSにはほとんど利点は無いと思っています。
現時点においては。
たぶんなのですが、まだ発展途中な概念だと思っています。
恐らくの最終目標はECU＆HILS構成の完全PCシミュレーション化と見ています。
HILSはかなり現実世界に近いシミュレーション方式なのですが、
ひとつ大きな弱点があります。
「狙ったタイミングに狙ったイベントを放り込めない」
業界用語つかってしまうと
「Fault(故障)注入がしづらい」
単純にセンサ系の断線、短絡の組み合わせであればHILSで十分ですが、
そこにタイミングが入ってくると少々難しくなりますし、中にはECU内部にセンサがあり、HILS側から操作できるようなインターフェースが無いものもあります。
故障があるということは復帰もあり得るということで、これらのタイミングもかなり鬱陶しい。
また、CANなどの通信を経由して他のECUから取得しているようなデータを使用している場合、CAN回線の異常検知のほかにCANコントローラそのものの異常検知も入ってきます。
CANコントローラはECU内部どころかマイコン内部に存在します。
つまり、usオーダーのタイミングのズレやECU内部の故障はHILSでは再現できません。
さらに複数のECU間の故障検知のタイミングのズレなんかも加味したら、内容の重みは無視して数だけで言ったらできないことの方が多いです。
そういった外からでは制御できないイレギュラーな状態を食わすための第一世代がSPILSだと思います。
これに各種ペリフェラルやマルチコア要素、並列に動作させてECU間通信などの各種部品を揃えたものが次世代となります。
当然各種部品はわざと壊れる振る舞いをする機能を入れ込む必要がありますが、
こういったものが出揃えばもしかしたらSPILSという言葉自体がなくなるかもしれません。
とはいえ、誰が各種部品を用意するのかってのが大きな課題になります。
普通に考えれば、半導体メーカの範疇になりそうなのですが、実際の部品ではなくシミュレータにつなぐ部品を作れっていうのはかなり難色を示すでしょう。
部品が揃っても繋がなければ意味がないので、それも誰がやるのって感じです。
ECUサプライヤの領域な気がしますが、先進的なサプライヤでなければ少々厳しいです。
多種多様の業種が入り混じり、自動車業界ではちょっとめずらしく、深さではなく、広さを求められる特殊な領域になりそうです。
コメント