ARMは3月26日、Cypressと共同で記者説明会を開催し、同社の自動車向け製品に関する取り組みを説明した。

最初に書いておけば、今回の説明会では基本的には新しい製品とかテクノロジーが説明された訳ではなく、既にARMが提供しているものが再説明されたに過ぎないのだが、それでもわざわざ説明会を開いたというのは、こと国内ではARMのアーキテクチャはSmartphone/Tabletなど向けで、自動車関係では一部のInfortaiment機器向けに利用されている程度、という認識が多く、これを正したいという意図があったのでは無いかと思われる(Photo01)。

Photo01:前半部の説明を行ったRichard York氏(VP, Embedded Segment Marketing)。前回はSTMicroelectronicsのTM32F7の説明会の際に来日した。

ARMの自動車向けストラテジー

さて、まずはARMのパートから。ARMがアドレスできる自動車向けマーケットはどんどん大きくなっている(Photo02)という認識がまずあり、運転システムの電子化・ADAS・運転情報とInfortaimentという3つの分野が急速に伸びると予測し、このマーケットを真剣に獲得したいと目論んでいる。既に同社のコアは様々なメーカーが製品に採用、自動車向けに導入が始まっており(Photo03)、決して同社が自動車業界に無縁と言うわけでは無い。ただこれらの市場はARM以外のコアも多く採用されているため、ここでARMの採用比率をより高めてゆきたい、という訳だ。

Photo02:例えば2020年で言うと50億ドルを超えるマーケットに対し、潜在的にARMはアドレスできることになる。ちなみにこの数字はあくまでSoCという括りで、例えばEV向けのパワートランジスタなどは含まれていない。

Photo03:ADAS向けにはXilinxやAlteraのSoC FPGAが採用されており、更に一部ではCortex-A53の利用も始まっているというのは興味深い。

では具体的にどんな用途向けに今後展開が考えられるのか、というのがこちら(Photo04～06)。特に運転席周りの場合、高級車向けにはHUD(Head Up Display)すらも次第に一般的な装備になりつつあり、逆に言えばHUDこそ持たないものの、従来高級車にのみ搭載されていたマルチファンクションタイプのコンソールはミッドレンジを超えて大衆車にまで広がりつつある。

Photo04:こちらはADASが主としたものだが、急速にこの分野が盛り上がってるのはご存知の通り。

Photo05:こちらは車内装備なので、当然車のグレードによって搭載する/しないは変わって来る。ただ、以前なら高級車向けだった機能が大衆車向けに、という形に広がりつつあるのも事実で、結果として搭載される機能が次第に増えてきている。

Photo06:運転席周りの高機能化は、これもご存知の通り。

Cortex-R5はまさしくこうした用途向けのMCUとして開発された製品である(Photo07)。どのあたりがコンソール用途向けかというと

・ EEMBC AutoBenchで、1.0 Automark/MHzの高性能(ちなみにPowerPC系だとこれを超えるのはe200v7コア搭載の製品のみで、殆どの製品は1.0 Automark/MHz未満である)

・ Green Hillsから自動車向けに最適化したコンパイラが提供される

・ ISO26262/IEC 61508の認証取得に必要なリソースが提供される

というあたりである。実は後半2つは製品そのものというよりも開発環境に関係してくる部分なので、ここをもう少し説明する。

自動車業界では最近MBD(Model Base Design)を利用した開発が序々に広まりつつある(Photo08)。といっても、現状ツールとしてはMathWorksのMATLAB/Simulinkが唯一のもので、あとはSynopsisの提供するVirtual Prototypeを初めとするツール類で試作を高速化する環境はあるが、ここで問題になるのはどちらを使うにしても、ターゲットデバイスはMATLAB/SimulinkなりVirtual Prototypeがあらかじめサポートしているものに限られる事だ。そんなわけで主要なプラットフォームベンダーは自社の製品がこれらのツールでサポートして貰える様に努力しているわけだが、ARMの場合主要なコアはもう既にサポートされているから、ここで悩む必要がなくなるのは大きなメリットである。

Photo07:コンソールの多機能化＝プロセッサの性能向上もまた必要なわけで、性能とリアルタイム性の両面を満足しつつ、更に機能安全までというとCortex-Mシリーズではやや荷が重く、Cortex-R系が適切、という訳だ。

Photo08:勿論、MATLAB/SimulinkなりVirtual Prototypeなりが対応していないプラットフォームに移植することも可能だが、その場合Implementationの段階で手作業が発生するから、問題の収束にも時間が掛かるし、MBD本来のメリットがだいぶ薄れることになる。

また、例えば途中で利用するSoCのベンダーを変える、あるいは新規に追加するといった話があっても、複数のメーカーが既にARM v8-Rベースの製品を投入しているから、同じCortex-Rベースの製品を選べば開発やメンテナンスの手間がだいぶ省けることになる(Photo09)。勿論これは諸刃の剣であって、逆に半導体ベンダーからすると長期的にはCortex-Rを搭載しただけでは差別化にならなくなるわけで、別の差別化要因を探さないと別のメーカーにシェアを簡単に奪われてしまう事にもなるのだが。

Photo09:短期的にこうした変化が起きるケースは稀だが、長期的には例えば東日本大震災の後、国内の自動車メーカーがセカンドソースを求める様になった事は記憶に新しい。