全5358文字
PR

 アイシン精機がソフトウエア開発体制を強化している。コネクテッドや自動運転といった新機能に対応する統合ECU(電子制御ユニット)は、従来のECUとは異なるソフトウエア開発体制が求められるからだ。自動車メーカーが独自に開発するソフトウエア基盤「ビークルOS」への対応も進める。

 「統合ECU(セントラルECU)の検討は約20年前からあった」。同社執行役員でソフトウエア開発のトップを務める電子センタープレジデント電子商品本部長の植中裕史氏はこう語る。

アイシン精機執行役員の植中裕史氏
アイシン精機執行役員の植中裕史氏
(写真:アイシン精機)
[画像のクリックで拡大表示]

 「セントラルECUにはさまざまな車種のバリエーションに対応しにくいという課題があった」(同氏)という。例えば、「高級車用にセントラルECUを開発すると、それは大衆車向けには高すぎる」(同氏)。大衆車から高級車まで幅広い車種を取りそろえる自動車メーカーには、この点が大きな壁だったという。

 これに対し、新興電気自動車(EV)メーカーの米テスラ(Tesla)は、いち早くセントラルECUを採用した。それは「過去のしがらみがなく、車種のバリエーションも高級車のみで少なかったからではないか」(同氏)とみる。

 最近では、日本の自動車メーカーでも車載ソフトウエアの規模が大きくなり、パワートレーンやボディーなど領域(ドメイン)ごとにドメインECUを配置する「ドメインアーキテクチャー」が主流になってきた。今後、コネクテッドと自動運転を連携させるような大規模システムが入ってくると、セントラルECUが必要になるという。

 ただ、「すべてがセントラルECUに置き換わるわけではない」と植中氏は指摘する。センサーやアクチュエーターの制御を伴うシステムの場合、セントラルECUに機能を取り込むことが難しい。例えば、「アクチュエーターの動きをセンサーで検知しながらリアルタイムに制御するようなシステムでは、ECUをアクチュエーターの近くに配置しないと通信が成り立たないことがある」(同氏)。いわゆる“反射神経”に相当するような部分は、従来型のECUを必要とする。

 アイシングループでは、こうした従来型のECUに加え、セントラルECUの開発も進めている。従来型のECUの場合、ソフトウエア開発手法はあまり変わらない。仕様書を厳密に作り、ソフトを実装して、テストをする「ウォーターフォール型」と呼ばれる手法が多い。最近はその中でも、仕様書の代わりに「シミュレーションモデル」を使って、上流工程で十分に機能を検証してから実装する「モデルベース開発」に力を入れているとのことだった。

 一方、セントラルECUでは「アジャイル型」や「スクラム型」といったIT分野で使われている開発手法が求められるという。仕様書が厳密に固まる前に、まずは“動くソフトウエア”を作って提供し、ユーザーのフィードバックを受けながら修正を重ねて完成度を高める。こうした手法は、トヨタグループで自動運転ソフトを開発するTRI-AD(トヨタ・リサーチ・インスティテュート・アドバンスト・デベロップメント)が取り入れている(関連記事)。

 アイシン精機はTRI-ADに出資し、技術者も出向させている。米国シリコンバレーでソフトウエア開発を経験したTRI-ADの技術者から、ノウハウを吸収している。「出向メンバー以外も、TRI-ADのスクラム開発の研修を受講したり、スクラムマスターの資格を取ったりしている」(植中氏)。セントラルECUを使うコネクテッドや自動運転、運転者監視システム(DMS)の開発では、こうしたIT分野のノウハウが欠かせないようだ。

ビークルOSに対応

 セントラルECUには、自動車メーカーが独自に開発したソフトウエア基盤「ビークルOS」を搭載する動きがある。ドイツ・フォルクスワーゲン(Volkswagen、VW)が新型EV「ID.3」に搭載した「vw.OS」や、TRI-ADが開発中の「アリーンOS(Arene OS)」などが代表例だ。

アリーンAPIを通じて、自動運転アプリなどを開発できる。開発したアプリは「アリーンOS」を搭載した車両で動作する
アリーンAPIを通じて、自動運転アプリなどを開発できる。開発したアプリは「アリーンOS」を搭載した車両で動作する
(出所:TRI-AD)
[画像のクリックで拡大表示]

 ビークルOSでは、独自のAPI(Application Programming Interface)を通じてさまざまな機能を実現する。このため、セントラルECU向けのソフトウエア開発では、自動車各社のAPIにうまく合致するようなソフトウエア構造設計(ソフトウエアのモジュール化)が欠かせない」(同氏)とする。

 このような開発は、アイシン精機本体のほか、2019年10月にアイシン・コムクルーズとエィ・ダブリュ・ソフトウェアを経営統合して設立したアイシン・ソフトウェアでも進めている。アイシン精機がビークルOSに合致するソフトウエア構造の仕様を決め、その方針に基づいてアイシン・ソフトウェアがモジュールを開発する。ただ、「実際には一緒にやっており、アイシン精機がモジュールを開発したり、アイシン・ソフトウェアが上流のソフトウエア構造を設計したりすることもある」(同氏)。

 植中氏によると、自動車メーカーがビークルOSを自前で開発する理由は大きく2つある。1つは、ソフトウエア開発がクルマ開発のボトルネックになりつつあることだ。「開発リードタイムも、開発費も、ソフトウエアがかなりの割合を占めている。効率的にソフトウエアを開発するための基盤技術(インフラ)を手の内化し、競争力を高める狙いがある」(同氏)とする。

 もう1つは、ソフトウエアそのものが収益につながることだ。OTA(Over The Air)によるソフトウエア更新で自動運転などの機能を追加・改善できれば、クルマ自体の価値が上がる。「ソフトウエア単体で事業が成り立つ可能性がある」(同氏)。また、クルマをIoT機器ととらえ、ビッグデータを集めて新たな価値を生み出すことも可能だろう。そのカギを握るのが、効率的なソフトウエア開発を可能にする基盤技術である。

 スマートフォンの業界では、米アップル(Apple)の「iOS」や、米グーグル(Google)の「Android」がある。Androidは他社にも提供するオープン型だが、iOSは自社のみに限定するクローズド型である。「おそらく、ビークルOSも各社の戦略によって、さまざまな形態があるのではないか」と植中氏はいう。少なくとも、VWはvw.OSの外販を視野に入れている(関連記事)。アリーンOSは開発中であり、不明な点が多いが、基本的なコンセプトはオープン型のように見える。

 1次部品メーカー(ティア1)やソフトウエアベンダーにとっては、ビークルOSの種類が少ない方が開発効率は高まる。現時点でビークルOSを大々的に掲げているのはVWくらいだが、今後他社も同様のビークルOSを出してくると、業界全体で開発効率が下がるリスクがある。一方、ビークルOSの開発には巨額の投資が必要なことから、世界で3方式くらいしか生き残らない、との見方も出ている(関連記事)。

 ビークルOSを業界全体で標準化する動きとしては、AUTOSAR(AUTomotive Open System ARchitecture)がある。従来型のECUに対応する「Classic AUTOSAR」に加え、セントラルECUに対応した「Adaptive AUTOSAR」の採用が今後本格化するとみられる。vw.OSも要素部品としてはAdaptive AUTOSARを使っているとみられるが、アプリケーションとのAPIは独自に決めているようだ。ちなみに、アイシングループもすべてのソフトウエアを自前で開発するのではなく、必要に応じてAUTOSARコンポーネントを外部から購入することで効率化を図っているという。

 もう一つ、セントラルECUやビークルOSの議論で重要な点は、ハードとソフトが切り離される点だ。ビークルOSが稼働すれば、ハードは自由に入れ替え可能になる。従来型のECUはハードとソフトを切り離すことが難しく、ティア1はハードとソフトを一体化して販売してきた。これに対し、セントラルECUではハードとソフトが分離し、ハード単体、またはソフト単体での競争力が問われる。「この点はティア1にとっては脅威だ」(同氏)という。