激変するモビリティアーキテクチャ、カギは「統合ECU」

モビリティには、ECU（Electronic Control Unit）と呼ばれるたくさんのコンピューターが搭載されており、これらECUがエアコンから運転支援までモビリティのさまざまな機能を制御しているそうですね。このECUのアーキテクチャが今、大きく変化しつつあるとお聞きしたのですが、いったい何が起こっているのでしょう？

松本：スマートフォンにたとえて説明しましょう。スマートフォンにはカメラやディスプレイ、通信などの機能が組み込まれており、それぞれの機能は別々のチップが制御しています。そして中心には個々の機能を統括するCPUがあり、全体の制御を行っています。
最近のモビリティでは、約100個のECUが各ドメイン（自動車の機能単位）の制御を行っているのですが、スマートフォンのCPUに相当する、全体を制御するECUはありませんでした。そこでモビリティ全体を制御する「統合ECU」を開発しようとしています。

そもそも、なぜ統合ECUを開発する必要が出てきたのでしょうか？

松本：一言で言うならば、モビリティの価値向上のため、ということになるでしょう。
モビリティはもはや単なる移動手段ではなく、社会の重要な構成要素です。クラウドを活用したサービスをユーザーに提供したり、交通制御システムと連携したり、さらに将来的には自動運転といった高度な機能を実現することが求められています。モビリティがそうした機能を実現するためには、車外と必要な情報をやりとりし、各機能を担うECU同士を連携させる必要があります。

例えば、クラウド上のサービスからモビリティの窓を開けるように指示を出したいとき、窓を制御しているECUに細かな指示を出すことは手間がかかります。クラウド上のサービスからは「窓を開けて」という指示を出せば、あとはモビリティ側で細かな制御を行ってくれることが望ましいです。

人間に対しても、「デンソー太郎という人間の、右腕にある××という筋肉を収縮、××という筋肉については伸展させる」と指示を出すのは面倒くさいですよね。「デンソー太郎さん、右腕を挙げてください」と指示を出したいわけです。
統合ECUがモビリティの各機能をつなぎ合わせ、外界との通信を担うことで、クラウドや私たちはモビリティを１個の存在として認識できるようになります。

統合ECUによって、どのようなことが実現するようになるのでしょう？

松本：1つは、アプリケーションによるサービスの高度化です。サードパーティが提供するアプリケーションも含め、車内外でアプリケーションを使ってモビリティを安全に操作したり、データを活用したりできます。これまでのECUはドメイン単位の制御を行っていましたが、統合ECUによって複数のドメインを跨いで制御するアプリケーションも開発できるようになります。

さらにアプリケーションによって機能を追加できるだけでなく、モビリティのシステム自体をOver The Air（OTA）、つまり無線経由で更新することも可能です。
そして高度な情報処理を行ううえで、個人情報保護や傍受／改ざんされないようにするセキュリティを担保することも、統合ECUの重要な役割になります。

これまでモビリティの分野では、セキュリティに関してあまり強調されてこなかった印象があります。

松本：今までのモビリティだと、出荷された後にプログラムが更新されることはほとんどありませんでした。ところがこれからのモビリティでは、OTAによってシステム自体を更新したり、サードパーティのアプリを追加したりできるようになります。その一方でこれにより、悪意あるプログラムが侵入するリスクも増しているのです。

モビリティのセキュリティに関する、デンソーの強みとは何でしょう？

松本：モビリティ全体について、ノウハウを蓄積してきたという点です。
従来のモビリティにも多数のECUが搭載されていますが、デンソーはほとんどのECUを自社で開発してきました。エンジンやブレーキなどの駆動系から、エアコンやドアに至るまで、フルラインナップのECUを手がけています。一方、カーナビを始めとして、クラウドとの接続に関しても技術を磨いてきました。

そして、デンソーのモットーは「いかなる時でも安全を守る」ことです。安心・安全を担保する技術と、コネクテッドの技術。エレクトロニクスの技術をよく知るデンソーがITと組み込みを繋ぐことで、次世代モビリティに不可欠な統合ECUを生み出せると考えています。

次世代のモビリティでは、どのようなセキュリティ技術が使われることになりますか？

松本：モビリティのセキュリティリスクとしては、いくつかのパターンが考えられます。
例えば、車両情報をクラウドにアップロードする際に個人情報が漏れてはなりません。そこで、アクセス権やIDを一括管理して個人情報を保護する、車両データサーバーを用意しています。
また次世代モビリティでは、車外からクルマの装備をコントロールする機会が増えますから、コントロールを要求しているユーザーや車両状態に応じて、認可を行う管理機構も開発しています。

車外からはさまざまなネットワーク攻撃がありえますから、事前防御、侵入検知、事後対策を備えたセキュリティシステムも開発中です。デンソーでは、ブロックチェーン技術を活用したデータ改ざん防止技術も研究しています。

• ブロックチェーンとモノがQRコードで結びつく

これまで各ECUが担っていた役割を、すべて統合ECUが担うことになるのですか？

松本：一部の機能については統合されますが、すべてではありません。従来ECUの多くは、一定時間（例えば5msec）以内のリアルタイム処理を保証するために、マイコン上にスケジューラ（周期駆動）ベースのソフトウェアを実装しています。こうした従来ECUをすべて1つのECUに統合するのは、あまりにもドラスティックで現実的ではありません。
統合ECUが各ECUの機能をソフトウェア的に束ねる、といった方がイメージに近いと思います。

統合ECUは従来ECUとは役割がずいぶん違いますが、開発プロセスも変わることになるのでしょうか？

森：これまでのECU開発の多くは、ウォーターフォール型でした。安全に関わるECUは特にそうです。ウォーターフォール型とは、仕様を固めて設計して実装し、検証・妥当性確認を積み上げて品質を保証するという開発手法で、品質と安全を指向した手堅いスタイルです。
また従来のECUは、OEM（完成車メーカー）からサプライヤーが受注した後は、ハードウェア、ソフトウェア、アプリケーションまでサプライヤー1社で責任を持って仕上げるのが一般的でした。サプライヤー社内で、ハードウェアやOS、アプリケーションを相互調整しながら「すり合わせ」で開発してきたのです。

しかし、統合ECUは、ウォーターフォール型では開発できないと。

森：はい。ウォーターフォール型の大きな問題の1つは、アダプティブな開発。つまり仕様を市場の動向に合わせて柔軟に変えていくソフトウェア開発が困難であることです。

すり合わせに関しては、チームメンバーがアイデアを持ち寄って難しい技術課題を解決できるなど、良い面もたくさんあります。しかし設計不足を後から埋め合わせできてしまうため、あらかじめ全体設計を見通して相互調整しておくべき点までも、後回しになってしまうデメリットがありました。

統合ECUの開発プロセスは、ウォーターフォール型一辺倒のやり方にはなりません。なぜならば統合ECUには、どんどん進化していくアダプティブに作るべきソフトも搭載されるからです。そうしたソフトウェアについては、アジャイル開発を可能にするプロセスが必要になってきます。

また、これまでのECUの主流であったサプライヤーの１社完結型とは異なり、OEMとサプライヤーがハード、OS、アプリケーションを分担する、連携型の開発になります。
開発の上流工程で統合ECU全体のアーキテクチャを設計し、その設計に基づいてハードウェア、OS、アプリケーションを並行開発。最後にそれらをインテグレーション（統合）するのが基本的なフローとなります。

どのように統合ECUの開発を分担することになるのでしょう？

松本：OSに関しては、OSベンダーが開発したものをOEMが調達するのが一般的です。自動車業界には、車載ソフトウェアの共通化を目指して設立されたAUTOSAR（AUTomotive Open System ARchitecture）という団体があります。AUTOSARは、アダプティブなソフトウェア開発を可能にするプラットフォーム「AUTOSAR Adaptive Platform」の仕様を2017年に発表しており、これに準拠してOSやハードウェア、アプリケーションの開発を行うメーカーが増えています。

統合ECUで言えば、SoC上にAUTOSAR Adaptive Platform準拠のOSを搭載。サードパーティも含めた各種アプリケーションは、AUTOSAR Adaptiveのサービスを呼び出すことになります。従来は個別のECUが担っていた電源やエアコン関連の機能は、統合ECU上のアプリケーションとして取り込んでいます。

OSの機能をアプリケーションが呼び出すというのは、パソコンやスマートフォンと似ていますね。

松本：いわば1棟のマンションを造るようなものですね。各人に応じたサイズの部屋を割り当てて、部屋と部屋を仕切る壁をきちんと造る。その一方で、水道管やガス管は共有できるようにしなければなりません。

森：現在のモビリティのソフトウェアは、従来ドメイン領域と進化領域の2つに大きく分かれます。
従来ドメイン領域のソフトウェアには、エンジン制御といった人の命に関わる分野の制御ソフトウェアが含まれます。仮にモビリティの開発期間が2年だとしたら、従来ドメイン領域のソフトウェアは2年前には仕様が固まっていますが、高い信頼性とリアルタイム性が要求されるという難しさがあります。

一方で進化領域の代表といえば、クラウドなどと連携するコネクテッド機能などです。こちらは製品が発売される1年前・半年前に仕様が変わることもあります。市場動向やお客様のご要望にあわせて仕様を変えるのですが、すでに使えるメモリもストレージもいっぱいの中で、リソースをやりくりする難しさがあります。

従来ドメイン領域と進化領域では、まったくソフトウェア文化が違ってくるんですね。

森：先ほどのマンションの部屋割りで言えば、さまざまなソフトウェアに同居してらうために、部屋の仕切り方も変えなければなりません。工事しないと動かせない頑健な壁で仕切る部屋と、シェアハウスのようにプライバシーは保持しつつもキッチンは共有、というタイプの部屋を使い分けて、異なる文化のソフトウェアに同居していただきます。

こうした同居があることから、統合ECUは、従来ドメイン領域と進化領域という2つの領域でソフトウェア開発を行うことになります。
統合ECUは個々のECUを束ねる機能と外部との通信機能を備えるべく、モビリティ全体のアーキテクチャと調和させる必要があります。その上で、従来ドメイン領域と進化領域という異なる2つのソフトウェア開発文化も両立させなければなりません。

安心・安全というモビリティの大前提はきちんと守りながら、アジャイル的な開発にも対応。それをOEMやサプライヤーで分担しながら開発していかないといけないのですね。これほど複雑で大規模なソフトウェア開発となると、従来とは大幅に開発体制を変える必要があるのではないでしょうか？

松本：その通りです。これまでデンソーがECUを開発する場合、各部署で開発を進めていました。
しかし統合ECUは1つの部署だけで完結できるものではなく、従来の開発手法が通用しません。複数の組織で、色々な知見を集めなければ完成させることができないわけです。

そこでデンソーは、統合ECUを開発するための部門横断チームを立ち上げました。ここで力を発揮するのが、デンソー独自開発のツール群です。（後編に続く）