先端のシミュレーションが、カーエアコン開発を変革する

クルマの標準装備となっているカーエアコンですが、技術的に今大きな変化が起こっているとお聞きしました。そもそもカーエアコンでは、どういう制御が行われているのでしょうか。

冨田：カーエアコン制御の基本は単純です。まず、外気温、車内気温、日射量などの各センサーとユーザが設定した設定温度から、ユーザーが快適と感じる吹出し温度と風量を算出します。そして外気を取り入れるか内気を循環させるか、どの吹き出し口から風を出すのかを決め、エアコンを制御します。クルマの場合、窓が曇っては走行できませんから、湿度が高くなりすぎないように調整することも重要になってきます。
基本は単純ですが、車内を快適にするためにやっていることはけっこう複雑です。今のクルマでは運転席と助手席で違う温度設定にできるものも一般的になってきましたし、上半身と下半身でも違う温度に設定できるようにもしてあります。冬場でも日射が強いときは、足元は温かく、顔には冷たい風が当たるようにする。送風にしても、足元から出る風とフロントガラスに当たる風の割合を何段階かで制御し、快適性を損なわず、なおかつ窓が曇らないようにして視界の安全性を保っています。

カーエアコン自体には何か大きな変化があったのでしょうか。

冨田：極端なことをいえば、従来のカーエアコン制御は冷房に専念していました。コンプレッサーを制御して冷たい空気を作り、それをエンジンからの熱とどういう割合で混ぜ合わせるのかを考えていればよかったわけですね。
ところが、HEV（ハイブリッド車）、さらにはPHEV（プラグインハイブリッド車）やBEV（電気自動車）が登場してきたことで、状況が変わってきました。
まずハイブリッド車ではバッテリー駆動することが増えたため、エンジンを頻繁に止めるようになりました。ガソリン車ではカーエアコン用コンプレッサーをエンジンで動かしていたのですが、ハイブリッド車のカーエアコンは電動コンプレッサーを使わなければなりません。そうなると、カーエアコンのためには電動コンプレッサーの制御も行う必要が出てきます。
さらに、プラグインハイブリッド車のEVモードやBEVではカーエアコンの熱源としてエンジンを使うことができないため、ヒートポンプが採用されるようになりました。ヒートポンプは、冷媒を圧縮／膨張させ、外気との熱交換を行う仕組みです。家電のエアコンでは冷媒を逆向きに流すことで冷房／暖房の切り替えが行えるのですが、クルマでは暖房中でも車室内の湿度が上がって窓が曇ってしまうような場合は冷房しながら暖房することが必要です。そのため、ヒートポンプとは別に暖房用のヒーターを用意する場合があり、こちらの制御も行わなければなりません。また冷媒の流れを切替えて冷房/暖房だけでなく除湿暖房もできるようにする機能も開発しています。

ヒートポンプとヒーターの両方をバランス良く制御するとなると、手間は2倍どころか2乗くらい大変になっていそうですね。

冨田：まさにそういう感じがします。ヒートポンプによる冷房／暖房、ヒーターによる除湿暖房という3つの運転モードを用意し、どういう状況の時にどのモードに切り替えるかを判断するアルゴリズムを開発しました。また、バッテリーが熱くなると車両からはバッテリーを冷却しろという要求が出されますし、HEVではエンジンを駆動する要求も出されます。そのため、車両メーカーとも仕様について細かくやり取りしています。
そして、人間にとって一番快適な環境を実現するために、温度センサーがたくさん付いたサーマルマネキンという人形を使ったり、全部の吹き出し口に温度計を入れたりと、細かく温度を測定して分析を行います。
こうした分析を元に、カーエアコンを制御するECU（Electronic Control Unit：電子回路の制御装置）の仕様書を私たちの部署で作成していきます。仕様書は1車種につきA4用紙で2000ページにもなり、この仕様書に基づいてECUを制御するプログラムコードが書かれます。
厄介なことに、車両の気密性などは部品がちょっと変わるだけでも変化するため、車両が全部でき上がった状態でないと、完全には空調を評価することができません。そのため、クルマ開発の最終段階直前にもカーエアコンの仕様変更はありえるのです。

快適性と安全性を高めるために、複雑なプロセスが必要なんですね。

川井：カーエアコン制御のシステム開発では、V字開発プロセスという手法が採られます。要件定義、基本設計、詳細設計、制御モデル構築と進んだら、今度は単体テスト、結合テスト、システムテストとテストを進めて、要求仕様通りにECUのプログラムができているかを検証するのですが、カーエアコンではこのV字が3回ほど描かれることになります。

カーエアコンの制御はどんどん複雑になっていると伺いましたが、そうなると開発期間も長くなっていくのではないでしょうか。

川井：そうした課題を解決するために、現在進めているのが「モデルベース」によるシステム開発です。
「モデル」とは、システムがどのような構造になっていてどういう動作をするかを図で表したものと言えます。例えば、このコントローラーモデルは、センサーなどからのインプットに対してECUがどのような計算を行い、モーターやコンプレッサーなどのアクチュエーターにどのようなアウトプットを送るかを示しています。アクチュエーターが動作した結果は、またセンサーからのインプットとなって、コントローラーに送られることになります。

カーエアコンの制御に必要な、ECUやセンサー、アクチュエーターの動作がすべてコンピュータ上でシミュレートできると。

川井：はい。先に述べた従来のV字開発では、要件定義で行った通りの動作をするかどうか、実際にモノとしてのECUを作り、それで検証する必要がありました。しかし、モデルベース開発であれば、詳細設計まで進んだ後も、引き続きコンピュータ上でテストすることができます。

最終的には、ECUの実機を作ってテストすることになると思うのですが、それはどうするのですか。

川井：シミュレーションソフトウェア上に構築されたモデルの中からECUを選ぶと、C言語（プログラミング言語の一種）のソースコードが出力されますから、それをECUの実機に組み込むことになります。従来の開発では、仕様書を元にプログラマーがC言語でコードを書いていたわけですが、モデルベース開発において人間はソースコードを書きません。

モデルベース開発ではモノを作らずに、シミュレーションソフトウェア上で試行錯誤を繰り返せると。

川井：はい。これまでですと、ECUの実機を作って顧客に納品し、動作を検証していました。動作の不備が見つかるともう一度V字のプロセスを回して、再度ECUを作って……というように何回もV字を繰り返さなくてはなりませんでした。モデルベース開発では、作ったモデルをコンピュータ上で検証して問題があれば、そこで修正することができます。途中で小さいループを何度も回せるので、結果的に大きなV字の回数を減らすことができます。

大幅に開発期間を短縮できそうですね。

川井：実をいうと、現在進めているモデルベース開発のプロジェクトは、量産車向けとしては初めてのものであり、どれくらいの効率化ができるかはまだ完全にはわかっていません。ただ、従来に比べて、半分から4分の1くらいにはできそうです。
また今後、顧客ごとにカスタマイズの要求があった時にもモデルベース開発であれば、すばやく対応ができるでしょう。

いつ頃から、モデルベース開発に取り組まれたのでしょう。

川井：量産車向けにモデルベース開発を行うプロジェクトが始まったのは2018年からです。しかし、実は10年以上前からデンソー社内ではシミュレーションソフトウェアによるモデルベース開発を先行開発に用いていました。先行開発というのは社内で基礎技術を開発するフェーズのことです。シミュレーションソフトウェア上で作成したモデルを先行開発専用ECUに入れ、開発用装置や試作車でトライアル＆エラーで制御機構を作る取り組みを行っていました。

先行開発で作成したモデルは、量産開発には使わなかったのですか。

川井：先行開発でいったんECUのモデリングはするのですが、量産開発では作りこむ精度も異なっていたためにそのモデルは使わず、紙の仕様書を作り、V字開発を行っていました。つまり、V字の左上と下の方ではモデルが分断されていたのです。

何か技術的なブレイクスルーがあったのでしょうか。

川井：技術的というより、システム開発に対する考え方が変化した面が大きいと思います。以前は、それぞれのセクションで最適なツールを使おうという考え方が主流でしたが、メカとエレクトロニクス、ソフトウェアといった三つの技術を組み合わせた「三位一体」のシステム」の開発という考え方になってきました。これからの時代、ソフトウェア開発の比重はますます増えていくことになります。より効率的にソフトウェアを開発できるようにし、コストを抑える。そのためには、先行開発と量産開発でもモデルを合わせていこうと、全社的に考え方が変わってきました。

デンソー社内だけでなく、他のメーカーとモデルを共有して開発を進めることもあるのでしょうか。

川井：今、そういう取り組みがカーエアコンの開発で起きています。カーエアコン全体のシミュレーションを行おうとすれば、デンソー製のECUや部品だけでなく、他社のさまざまな機器やECUも関わってくることになります。これらがすべて協調して初めて、カーエアコンとして動作するわけですから。
そこで、デンソーが持っているモデル、お客様が持っているモデルを相互に提供し合い、モデルベース開発を行うようになってきました。

モデルベース開発によって、今後どのようなことが可能になると考えられていますか。

川井：現在のモデルは完成形ではなく、あくまでクルマの挙動のごく一部分を再現しているにすぎません。扱うパラメータにしても、温度や湿度など基本的なものだけです。
しかし、人間がクルマに乗り込むと、車内環境を五感で感じることになります。クルマで走っている時に変な音や匂いがしたら嫌ですよね。
現段階では、音や匂いのテストは実機に頼らざるをえません。将来的に、こうした要素も物理式として再現できるようになれば、音や匂いの評価もモデル上でできるようになるかもしれません。

例えば、クルマのボディや個々の部品がどうやって共鳴するかといったことまでモデル化していくと。

川井：そうですね。ボディが変われば音も変わるため、今は実機で一品一品確認していますが、そういうこともコンピュータ上で再現できるようにしていきたいと考えています。

どういう環境が快適かは大きな個人差がありますが、そうした要素もモデル化できるようになるのでしょうか。

冨田：最近だと、赤外線センサーを使って座席に座った人の皮膚温を測り、カーエアコンの温度を制御するという研究も行っています。

川井：皮膚温と体感とどう相関するのかがわかってくれば、それをモデル化して、さらに人に寄り添ったカーエアコンを作ることもできるでしょう。

将来的にはソフトウェア上でモデルを描いて、シミュレーションを繰り返し、1、2回試作したらカーエアコンのでき上がりというようなことも実現できたりするのでしょうか。

川井：はい、そういう方向性を目指して、モデルベース化を進めています。ものづくりは時間もコストもかかりますから、なるべく実物を作らないようにするのが、クルマづくりにおける大きなテーマです。

クルマというモノづくりが、どんどんソフトウェア化していくのですね。そうなると、開発に必要なエンジニア像も変わってくるのでしょうか。

川井：モデルベース開発といっても、すべてがソフトウェアで閉じた世界ではありません。ハードウェアの動作とソフトウェアの動作、その両方を理解していないと、シミュレーションでの振る舞いが妥当かどうかもイメージできませんから。カーエアコンのシステム全体について理解した上で、ソフトウェアとしてのモデルを作れる、そういう人材が必要になるでしょう。
また今後ソフトウェアファーストの流れが進めば、開発の上流と下流でのコミュニケーションも増えていきます。お互いがどういうことをやりたいと思っているのかを理解する、そういうコミュニケーション能力が求められるようになると思います。