車載向けマルチコアマイコン向けに、ソフトウェア開発ツールを提供 - ルネサスエレクトロニクス

周知の通り、昨今の自動車向けの組み込みデバイスには、非常に多くのSoC、マイコンが利用されている。SoCが採用される分野の多くはインフォテイメント向けや、最近だとADASと称される安全運転のためのアシスト機能であるが、実はECU(Electronic Control Unit)の内部で利用されるマイコンの高機能化・高性能化といった面でも、進化は著しい。これはつまり、それだけECUに求められている機能や性能が高まっているということだといえる。

マルチコア化が進みつつある、ECU向けマイコン

先に触れたECU向けのマイコンについて、近年マルチコア化が進みつつある。理由はまず、安全性の確保だ。Lockstep機構と呼ばれる冗長化機構を搭載するのには最低2コアが必要になるためである。加えてそれとは別の理由として、性能的にシングルコアではプロセッシングパワーが不足してきたため、という点も無視できない。背景として、車載のECU向け用途の場合、動作温度範囲の幅広さが求められることが挙げられる。冷却が難しい(防水・防塵・防振などの目的でがっちりとしたハウジング内に収められるのが普通なので、強制空冷はもとより自然空冷すら難しい)という制約があり、コアの動作周波数をそれほど引き上げるわけにはいかず処理の増加に対応しづらい。その代わりにマルチコア化する事で性能を高めようというわけだ。このトレンドは、自動車向け半導体を製造しているメーカーに共通だと言える。

少し前置きが長くなったが、大手半導体デバイス メーカーであるルネサス エレクトロニクスも、こうしたトレンドに沿った形で製品を提供している。同社はECU向け32ビットマイコンとして、RH850ファミリをラインアップしており、この中にはLockstepを目的としたものではなく、性能向上を目的としてデュアルコア構成となっているものも存在する。性能的には十分にニーズを満たせるものであるが、ソフトウェアの開発で従来にはない課題が発生するという。

自動車業界においては、特に機能安全規格であるISO26262の中で、MBD(Model Based Development)を利用したソフトウェア開発の手法が要件として定められている。その背景で、(特に)ECUのような安全性に直結する部品においては、MBDを利用したソフトウェア開発は必須だと言える。ところがMBDには現状若干の制約がある。現在のMBDは、シングルコア環境向けにはリアルタイム制御を正確に実装するためのコード生成が可能だが、マルチコア環境向けとしては、一般的なSMPに対応したPOSIXなどにしか対応していない。これはすなわち、マルチコア環境においてはリアルタイム制御を考慮しない環境向けのコードしか生成できないことを意味し、そういった用途には向かないといえる。

もちろん、ハンドコーディングを行えば色々と技法はあるのだが、それではMBDの意味が無い。MBDを用いながら、マルチコア環境でリアルタイム制御の出来るソフトウェア環境が求められているのだ。この話は単に自動車業界に限らない。ISO26262の功績もあり自動車業界ではMBDがすでに当然となっているが、産業機器や医療機器などにもMBDは普及し始めており、当然こうした業界でも同じ問題がでてくるからだ。

今回ルネサスが取り組んだのは、まさにこの「マルチコアを扱えるMBD環境の開発」である。今回お話を伺ったCPUシステムソリューション部 城倉 梨香 氏とツール技術部 佐藤 光一 氏は、同社の車載向け32ビットマイコンRH850ファミリのマルチコア環境に対応した、MBDベースのシミュレーションとコード生成環境に携わっている。

MBD環境上でどのようにマルチコアを扱うか

「自動車業界のお客さまにおけるマイコン採用の幅が広がるにつれ、『MBD環境でどのようにしてマルチコア環境を使いこなせばいいか』という課題をよく耳にするようになりました」。こう語るのは、自動車向けのマルチコア・ソリューションを担当する城倉氏だ。これら顧客の悩みを解消するべく、長年ツールの研究を行っていた佐藤氏に、MBDに適用できるツールの開発を依頼することに至ったという。

「すでに自動車業界のお客様は、モデルで仕様を記述して開発を行う、という状況であり、従来のC言語やアセンブリ言語で記述していた時代の開発とは状況がまったく異なっている」と城倉氏が語るように、城倉氏自身も「モデルで記述すると並行して動きそうな部分が各所で見受けられるのに、実際にコードを生成するとシーケンシャルで動いている様子がとてももったいない」と感じていたという。

ちなみにモデル化への要望に関しては、「ハイエンド向けの大規模なシステムよりもむしろ小規模なシステムに対する要望が強い」(佐藤氏)との事。理由の1つとしては、あまり大規模なシステムだとモデル自体が大きくなりすぎ、ハードルが高くなるからと推察される。実際、自動車のコンポーネントシステムとして、関連、派生するECUの数が比較的少ないワイパーの制御などではすでに、MBDベースの事例がある。こうした小規模なコンポーネントシステムについては、車両制御のほとんどの部分でMBDベースの開発に取り組んでいるという。ここで述べた開発とMATLAB/Simulinkのかかわりについて同氏は、「全体のシミュレーションという意味ではMATLAB/Simulinkが非常に大きな役割を果たしており、開発はそれらを中心に、開発の各段階に沿ったさまざまなツールを組み合わせて使う形が一般的である」としている。

MATLAB/Simulinkを利用し、モデルベース連携環境を構築

さて、そのMATLAB/Simulinkを利用したMBD連携環境は、具体的にどのようなものであろうか。これはPhoto04の様なSimulinkのGUI上で操作可能なツールで、これを利用して内部のSimulinkブロックごとに、マルチコアマイコンのどのCPUコアを使ってそのブロックを処理させるかを指定し、即座にそれをシミュレーションすることが出来るというものとなっている。このSimulinkのモデルからEmbedded Coderを利用してマルチコアに対応した並列実行可能なコードを生成し、それを実際の評価ボードに実装し、必要な制御周期内で処理できるかを確認することも出来る(Photo05)。ここでポイントとなるのは、Simulinkを利用する事で、仮想環境上で完全なシミュレーションが可能になることで、これによってしっかりとした検証が可能になる。

「モデル上でコア割当を指定すると何が良いかというと、もちろんEmbedded Coderでマルチコアのコードが生成できるのも良い点なのですが、単にコードが生成されるだけでなく検証環境も提供できる事です。これは最初に設計する制御モデルと、実際の量産コードを生成するためのモデルを、『MILS(Model in the Loop Simulation)』と『PILS(Processor in the Loop Simulation)』と呼んでいますが、このPILSがターゲットボードで動かした場合の結果になるのです。この2つを同じ環境上で実行して一致を確認するテスト、『Back-to-back Test』と呼ばれるものですが、これが可能になるのがこの環境の非常に大きな利点だと思っています」(佐藤氏)。

実際にPhoto04で左下に４つ並んだグラフについて、一番上がPILSを利用した場合の出力波形、２番目がMILSでの波形であり、これを比較することでモデルが正しくEmbedded Coderを利用してマルチコア向けの並列化コードができていることが確認できる。シングルコア環境ではそう珍しいものではないが、マルチコア環境で行うのはかなり大変なこの比較は、双方のコアの同期を取りタスクを分散して動かす事が可能になって初めて実現したという。上手くタスクを分散させないとむしろ所要時間が増えてしまったりするが、このタスク分散をどう設計すべきかについても、ボタン1つでパラメータを変えながらシミュレーションを繰り返す事で、より効率の良い構成に向けた最適化が短時間で行える事になる。この画面では表示されていないが、実際の各CPUコアの稼働状況や、あるブロックがどの程度の処理時間を要するか、あるいはその処理負荷の分散についてなども確認することが可能だ。

2016年春でのリリースを目指し、開発と検討を進める

「Embedded Coderが生成したCコード関数は、モデルブロック図の1つ1つのブロックに対応しており、今は計測の手段を色々試作している段階なのですが、もっと1つ1つの解析結果が見やすく示せるような形で近いうちにご紹介できるようにしたいと思っています」と佐藤氏が語るとおり、同ツールは現在、評価版的な位置付けにある。「実際にお客様に使っていただくと、さまざまなご要望や提案を頂くので、そうした声を新たに反映していく必要があるため」と同氏が続けるとおり、まだ完全に機能などは確定していないようだが、2016年の春頃には何かしらのリリースを予定しているという。

「マルチコアを扱えるMBD環境」は、マルチコアマイコンの用途がECUにまで広がっているいま、早期の整備が求められている。ルネサスエレクトロニクスによる環境整備について、今後の動きに期待したい。

（マイナビニュース広告企画：提供 MathWorks Japan）

[PR]提供：マスワークスジャパン