MathWorksがAUTOSAR/ISO 26262対応を強化、「コード生成が中核に」：欧州自動車メーカーが導入を加速（1/2 ページ）

車載ソフトウェアの標準アーキテクチャであるAUTOSARや、自動車向け機能安全規格のISO 26262への対応では設計ツールが重要な役割を果たす。The MathWorksのモデルベース設計ツール「MATLAB/Simulink」におけるAUTOSARとISO 26262への対応は、コード生成に用いるオプション「Embedded Coder」が中核になっている。

[朴尚洙，Automotive Electronics]

　自動車の電子化が進展する中で、それらの車載電子システムに利用されるソフトウェアは複雑化しており、その規模も急激に増大している。欧州の自動車メーカーやティア1サプライヤは、こういった状況にある車載ソフトウェアの開発効率や動作の安全性を高めるために、標準アーキテクチャであるAUTOSARや自動車向け機能安全規格であるISO 26262の策定を主導するとともに、それらの導入にも積極的だ。

図1　MathWorksのGuido Sandmann氏

　車載ソフトウェアの設計ツールベンダーにとっても、AUTOSARやISO 26262への対応は急務である。モデルベース設計ツール「MATLAB/Simulink」を展開するThe MathWorksで、欧州自動車市場のマーケティングマネージャーを務めるGuido Sandmann氏（図1）は、「設計ツールの中でも、AUTOSARとISO 26262の双方で重要な役割を果たすのが、MATLAB/Simulinkのオプション『Embedded Coder』に代表されるコード生成ツールだ」と語る。

トップダウンとボトムアップ

　AUTOSARは、ECU（電子制御ユニット）に組み込む車載ソフトウェアを階層化することにより、ソフトウェアの再利用性を高めたアーキテクチャだ（関連記事1）。その最上層に位置するアプリケーション層は、車載システムの個別機能や動作と関連する複数のソフトウェアコンポーネント（SW-C）から構成されている。Sandmann氏は、「AUTOARに準拠したSW-Cの開発では、トップダウンとボトムアップという2つの手法がある。トップダウンは、対象となる機能を新たに導入する際のアプローチで、自動車メーカーの要件設計から始まる。一方、ボトムアップは、既存のSW-Cやその元となったモデルを再利用できる場合だ。実際のところ、ECUのアプリケーション層を構成する各SW-Cの開発では、トップダウンとボトムアップが混在している。さらに、これらSW-Cは、検証/評価のために自動車メーカーとサプライヤの間を何度も行き来することになる」と説明する。

　こういった、サプライチェーンの中で何度もやり取りする場合には、設計/修正したモデルから何度もコードを生成することになる（図2）。このコード生成に広く用いられているのがEmbedded Coderである。「MathWorksは、トップダウンであれボトムダウンであれ、AUTOSARに最適なコードを生成できるようにEmbedded Coderをアップデートしている」（Sandmann氏）という。また、各開発プロセスでAUTOSAR対応のために導入されているツールとの相互接続性を確保するための取り組みも進めている。具体的には、AUTOSAR対応のアーキテクチャ設計ツールであるVector Informatikの「DaVinci」やMentor Graphicsの「VSA」、アプリケーション層とそれより下位のソフトウェア層を接続するツールであるVectorの「MICROSAR」やElektrobitの「tresos」などである。

図2　AUTOSARに準拠する車載ソフトウェア開発のワークフロー　車載ソフトウェアのサプライチェーンでは、「Roundtrip Engineering」（中央）と示しているように、モデルや生成したコードのやり取りを自動車メーカーとサプライヤの間で何度も繰り返すことになる。

　MATLAB/Simulinkの最新バージョン「R2011b」では、AUTOSAR準拠のECUを搭載する量産車の開発プロジェクト向けに最適化した「AUTOSAR Target Production Package」を投入した。同氏は、「AUTOSAR準拠のソフトウェアを搭載するECUの年間量産規模は飛躍的に増大するだろう。2010年は1000万〜1500万個だったが、2014年には1億個、2016年には2億個を突破すると見ている（図3）。今後も、顧客の要求に応えながらAUTOSARへの対応を着実に進めたい」と強調する。

図3　AUTOSAR準拠のソフトウェアを搭載するECUの年間量産規模