Special
» 2012年12月04日 10時00分 UPDATE

NIDays 2012講演リポート:ECUが100個超の時代、AUTOSAR最新版と仮想プロトタイプで車載開発を効率化

車載用電子制御ユニット(ECU)が自動車の安全・快適を一段と推し進めている。1台当たりのECU搭載数が増大するのに伴い、ECUが内蔵するソフトの開発負担が急速に高まってきた。そこで、開発負担の増加を抑制する動きが本格化している。ECUに依存しないソフト開発標準「AUTOSAR」のアップデート対応と、仮想プロトタイピングの最新状況をメンター・グラフィックス・ジャパンが解説する。

[PR/EE Times]
PR

 ECUに依存しないソフトウェア開発標準規格「AUTOSAR(オートザ)」のアップデートが進んでいる。AUTOSAR Release 3.X(AR3.X)に続いて2009年末に最新版のAUTOSAR Release 4.0(AR4.0)がリリースされたことで、現在は自動車メーカや車載電装品メーカ、マイコンメーカなどがAR4.0への対応を急いでいるところだ。

 これまで普及してきたAR3.1に比べると、AR4.0ではフルモデルチェンジとでも呼ぶべき大幅な変更がなされており、AR4.0への対応にはそれなりの期間を要する。大手自動車メーカでは、3年以上の期間を設けてAR4.0への対応プロジェクトを進めているところが少なくない。

 メンター・グラフィックスの調査では、AR4.0対応のECU開発で調達先(マイコンや設計ツールなど)を決定済みのECUは2012年に大幅に増加し、2011年と比較した場合には10倍以上になるとみられる。

AUTOSARの意義と普及

 AUTOSARの目的がECUに依存しないソフトウェア開発にあることは、最初に述べた。ECUはマイコンとファームウェア(ソフトウェア)、センサ、アクチュエータなどで構成されている。マイコンの品種ごとに独自のファームウェアを開発し、載せる必要がある。自動車1台が搭載するECUの数が10個未満と少なかった時代は、そういった開発手法が主流だった。

 しかし自動車1台当たりのECU搭載数が増大し、30〜50個といった数量になると、マイコンの品種ごとにソフトウェアを開発していたのでは、開発負担が非常に重くなり、自動車の開発期間全体に悪影響を及ぼすことになる。マイコンとは独立にソフトウェアを開発できる仕組みが望まれるようになった。このためAUTOSAR以前から、ソフトウェア開発を標準化する動きが始まっていた。

 AUTOSARは比較的最近になって標準化された規格であり、マイコンの依存性を排除する仕組みと、ECUの依存性を排除する仕組みの両方を備えている。またOSが存在するECUを前提とする。ソフトウェアは階層構造であり、最上層がアプリケーションであるソフトウェア部品(SWC)となる。SWCは実行環境(RTE)層の上にある。RTE層の下が基本ソフトウェア(BSW)で、ECUを抽象化する層やOS、通信スタックなどが含まれている。その下にマイコンを抽象化する層(MCAL)が存在する。

 AUTOSARの規格はRelease 1.0から始まり、バージョンアップを重ねてきた。AUTOSAR規格の普及が始まったのは、Release 3.1からである。

図1 AUTOSARが策定したソフトウェアの階層構造 図1 AUTOSARが策定したソフトウェアの階層構造(クリックで画像を拡大) 出典:メンター・グラフィックス・ジャパン

AR4.0で機能安全規格に対応

 AR3.1とAR4.0の間には、数多くの違いが存在する。最大の違いは「AR4.0で機能安全規格(ISO 26262)に対応したことだろう」とメンター・グラフィックス・ジャパンのテクニカル・セールス本部Advanced Systems Platformグループでマネジャーを務める三木研吾氏は述べていた。この他にもAR4.0では、パーシャルネットワーキング機能の搭載、基本ソフトウェア(BSW)機能の追加、メタモデルの全面変更、といった違いが存在する。

図2 メンター・グラフィックス・ジャパンの三木研吾氏 図2 メンター・グラフィックス・ジャパン テクニカル・セールス本部 Advanced Systems Platformグループ マネジャーの三木研吾氏である。NIDays 2012において、「AUTOSARを考慮した車載設計におけるトレンド」と題して講演した。

AUTOSAR対応ECU設計の実際

 AR4.0に対応したECU設計の各段階、すなわち、「システム設計」、「ネットワーク設計」、「ECUコンフィギュレーション」、「組み込みソフトウェア開発」、「テスト」、「ECUエミュレーション」といった段階では、それぞれ、設計ツールの助けを借りて開発を実行する。なおこれらすべてのツール群を単独で用意しているベンダは、メンター・グラフィックスだけである。

 車載システムのソフトウェア部品(SWC)はECUに依存しないので、SWCの設計段階では、ECUは見えない。その代わり、「仮想機能バス(VFB)」と呼ぶ内部接続の上に複数のSWCが載る。いわばVFBと呼ぶ“マイコン”の上で各ソフトウェアが動作している、仮想的な状態である。

 続いてSWCを複数のECUにマッピングする。それから各ECUに分割し、1個ずつ、ECUをコンフィギュレーションする。

図3 ソフトウェア(SWC)設計からECUコンフィギュレーションまでの流れ 図3 ソフトウェア(SWC)設計からECUコンフィギュレーションまでの流れ(クリックで画像を拡大) 出典:メンター・グラフィックス・ジャパン

仮想プロトタイピングでエレ/メカの開発期間を短縮

 メンター・グラフィックスの三木氏は、続いて、電気系(エレ)と機械系(メカ)が混在するシステムの開発期間短縮に不可欠な、仮想プロトタイピングの最新状況を説明した。

 仮想プロトタイピングとは、物理的な試作品(プロトタイプ)を作らずに、仮想的な試作品をコンピュータ内部に構築することで、設計仕様の検証を実施するとともに、ソフトウェアの開発を先行的に始める開発手法である。従来、システム開発ではハードウェアの仕様決定から始まり、ハードウェアの試作品を作る。試作品が完成した段階でソフトウェアの開発が始まる。ただしこの手法だとハードウェアの試作品が完成するまでソフトウェア開発が始められず、トータルの開発期間が長くなってしまう。

 そこでエミュレータとFPGAを活用して開発期間を短縮することが試みられた。ハードウェアの設計が完了した段階で、エミュレータとFPGAによって仮の試作品(プロトタイプ)を素早く作成する。このプロトタイプをベースに、ソフトウェアの開発を始める。ソフトウェア開発のタイミングが早まり、開発期間が短くなる。

 仮想プロトタイピングを使うと、ソフトウェアの開発段階をさらに早められる。システムの仕様を決定した段階で、仮想的なプロトタイプをコンピュータ内部に構築する。もちろんこの場合、システムの仕様策定を設計ツールベースで実施する必要がある。またハードウェア設計とソフトウェア開発が時間的に同時並行で進むことになるので、仮想プロトタイプを介してお互いの影響を反映させつつ、協調して設計を進行させなければならない。

EVパワートレインの仮想的な走行テストを実施

 講演では、メンター・グラフィックスのエレ/メカ統合開発環境「SystemVision」とナショナルインスツルメンツのシステム開発環境「NI LabVIEW」を連携させることで、仮想的な走行パターンテストを実施できることを示した。テスト対象は電気自動車(EV)とハイブリッド自動車(HEV)のパワートレインである。

 コンピュータ内部に構築した仮想的なプロトタイプのパワートレインで、走行パターンのテストを実施した。実際にパワートレインを物理的に試作せずとも、仮想プロトタイプによってさまざまな走行条件における車両とECU、モータなどの挙動を検証できるので、開発効率が大幅に向上する。

 具体的には、エレ/メカ統合開発環境のSystemVisionがパワートレイン(モータ)のモデルとなり、LabVIEWから道路の傾き(勾配)のデータを受け取って、走行情報(電力消費、車両速度、モータ電流、タイヤのすべり、など)をLabVIEWに返す。LabVIEWではこれらの走行情報を可視化してモニタに表示する。LabVIEWはその他、SystemVisionのツール「Envisage」にスロットルの開度情報を送信する。Envisage側ではC言語プログラムによるモータ制御を実施しており、スロットル開度の指令に応じてモータに電気信号を送出する。

図4 電気自動車(EV)の仮想的な走行パターンテストを実施 図4 電気自動車(EV)の仮想的な走行パターンテストを実施(クリックで画像を拡大) 出典:メンター・グラフィックス・ジャパン

 エレ/メカ統合開発環境のSystemVisionは、アナログ・デジタル混在回路に向けたハードウェア記述言語「VHDL-AMS」を利用しているので、回路シミュレータに比べるとモデルの抽象度が高い。このため、テストシミュレーションを高速に実行できる。

図5 NI LabVIEWのウィンドウに表示された走行テスト結果 図5 NI LabVIEWのウィンドウに表示された走行テスト結果(クリックで画像を拡大) 出典:メンター・グラフィックス・ジャパン

この記事に興味のある方におすすめのホワイトペーパー


= マルチドメイン・システムを開発/検証するための
仮想プロトタイピング環境 =

メンター・グラフィックスのSystemVision/SVXは、システムエンジニアならびに各設計分野のエンジニアが、コミュニケーション、シミュレーション、システムの最適化を行うために使用できます。


メンター・グラフィックスのSystemVision/SVXは、システムエンジニアならびに各設計分野のエンジニアが、コミュニケーション、シミュレーション、システムの最適化を行うために使用でき、最初のプロトタイプでの成功を可能にします。メンター・グラフィックスのSystemVision/SVXは、アナログ、ミックスシグナル、デジタル、エレクトロ・メカニカル設計のためのマルチドメインによる仮想プロトタイピング開発環境を提供します。

▼ ▼ ▼

 グラフィカルシステム開発とは?


Copyright© 2017 ITmedia, Inc. All Rights Reserved.


提供:日本ナショナルインスツルメンツ株式会社
アイティメディア営業企画/制作:EE Times Japan 編集部/掲載内容有効期限:2012年12月31日

Sponsored by

EE Times Japan Special

常識を打ち破るプラネタリウム製作を続けているイノベータ・大平貴之氏と、革新的なツールでイノベーションを後押しするサポーター企業・日本ナショナルインスツルメンツの池田亮太氏。NIDays 2012で、現代のモノづくりを2人が語り合った。

組み込みシステムが複雑化・多機能化するのにともない、開発プロジェクトには数多くの専門分野で構成される大規模な開発チームを必要とするようになってきた。システム開発プラットフォームであるNI LabVIEWは、少人数のチームで短期間に複雑な組み込みシステムを開発するための強力なツールである。日本ナショナルインスツルメンツの天沼千鶴氏がその詳細を語った。

車載用電子制御ユニット(ECU)が自動車の安全・快適を一段と推し進めている。1台当たりのECU搭載数が増大するのに伴い、ECUが内蔵するソフトの開発負担が急速に高まってきた。そこで、開発負担の増加を抑制する動きが本格化している。ECUに依存しないソフト開発標準「AUTOSAR」のアップデート対応と、仮想プロトタイピングの最新状況をメンター・グラフィックス・ジャパンが解説する。

高周波(RF)信号を扱う無線通信システムでは、設計/検証の負担が急激に高まっている。そこで、RF回路とデジタル信号処理の協調設計が重視されるようになってきた。RF設計ツールベンダのAWR Japanと、同ツールのユーザであり、「フルノ」ブランドの魚群探知機で知られる古野電気が、最新の事例を報告した。

RSSフィード

All material on this site Copyright © 2005 - 2017 ITmedia Inc. All rights reserved.
This site contains articles under license from UBM Electronics, a division of United Business Media LLC.