「名古屋オートモーティブワールド」で、JASPAR代表理事であり日産自動車理事でもある吉澤隆氏が「ソフトウェアは車の価値の源泉」という講演を行った。
業界ソフトウェアファーストの背景
電動化やコネクテッドによってもたらされる業界構造の変革は、ソフトウェアファースト、つまり、自動車ビジネスをハードウェアビジネスからソフトウェアビジネスに変えると言われている。こういうと、車のハードウェアに価値がなくなりソフトウェアがすべての価値になると思う人もいるが、実際はそう単純な話ではない。
EVになりソフトウェアによる制御範囲や可能性は広がるとしても、物体を動かす自然法則（物理）は変わらない。ボディやサスペンション、ドライブトレーンなどハードウェアの完成度が低ければ意味はない。ソフトウェアシフトが進んでも、ハードウェアたる車両本体や機構部分の価値が下がるわけではない。ソフトウェアシフトはハードの価値はそのままで、ソフトウェアの価値がアドオンされるということだ。
つまり、相対的にソフトウェアの価値が高まるが、ハードウェア価値の絶対値が変わるわけではない。したがって、車両本体の開発や技術は依然として重要であり、製品価値の源泉であり続けることになる。ただし、ソフトウェアによってもたらされる価値は、アドオン部分なので、いままでどおりでハードウェアの差別化だけでは十分ではない。これまでの車両性能をクリアした上で、新たな価値やビジネスを産まなければならない。
日産におけるソフトウェアファーストの取り組み
吉澤氏は、ハードウェアに直接かかわる機能価値として、日産が開発したe4ORCEを例に挙げた。e4ORCEは、VMC（Vehicle Motion Control）技術によって、雪道のような低ミューの道でもドライバーが進みたい方向に車を制御してくれる技術。VMCとは、ステアリングやアクセル、ブレーキのような機構の制御だけでなく、センサー技術、トラクションコントロールやブレーキ・サスペンションの電子制御を組み合わせることで、シャシーの動きを制御する技術だ。
ABSやタイヤの空転でアクセルを絞るといった個別機能に特化した制御ではなく、これらをソフトウェアによってインテリジェントに制御することで実現できる。
ソフトウェアの賜物という点では、プロパイロット2.0のような高度な運転支援システム同様だ。カメラ、レーダーなどによる360度センシング技術や3D高精度地図に、自動ブレーキや車線維持機能、VMCを組み合わせた走行支援は、すでにドライバーの操作より無駄な動きがなく正確で安定した走行を実現する。
そして、これらは安心・安全や疲労軽減といった効果、運転や移動の楽しみを強化する付加価値を生むことになる。他にも、EVならば災害時の家への給電や被災地支援としての価値が得られる。コネクテッド機能は、走行中・停車・駐車中のエンターテインメント、移動やメンテナンスの最適化、車両パーソナライズの強化などを実現する。それによって、クルマを周辺ビジネスも巻き込んだ、さまざまな体験を提供するデバイスとしてくれる。
モデル開発のスピードアップにCIツールを活用
以上のような変革は、これまでの車両設計や開発手法のままでは実現できない。吉澤氏によれば、すでに現在の車両コンポーネントは網の目のようにつながり、飛び交う信号は10,000種類以上だ。必要なプログラムコードの行数は6500万行にも及ぶ。2013年では1000信号数、3200万行だったものが急増している。
ソフトウェアがこれ以上肥大化すると、おそらく人間の手には負えなくなる。車両のE/E（電気/電子）アーキテクチャから考え直す必要があると指摘する。従来はコンポーネントごとにバラバラに制御する「ドメインアーキテクチャ」が一般的だった。制御部が高度化した現在は、各部をゾーンとしてまとめそれらを制御するECUを配置する「ゾーンアーキテクチャ」が広がっている。加えて、制御信号を多重化することで各部の結線（ハーネス）を減らす「スマートアーキテクチャ」というトレンドもある。
コネクテッド機能により、クルマのサービスプラットフォーム化が進むと、いままで以上の開発スピードも要求される。ADAS機能の高度化や自動運転ニーズもこれに拍車をかける。たとえば「プロパイロットの開発では10万キロ以上の路上走行テストを行ったが、2.0ではそれ以上が求められた。いまでは30万キロ以上の世界に入っているが、現実的にはシミュレーションを活用しなければ追いつかない。」（吉澤氏）
ソフトウェア開発をいかに効率よく行うか。自動化できる部分はツールを使って自動化することも重要だ。開発スピードをあげるために吉澤氏が注目したのはCI（Continuous Integration）ツールだという。CIツールは、Webサービスやクラウドシステムの開発で一般化している手法だ。コードのバージョン管理、テストの自動化、ビルド（プログラムのコンパイルや構成設定などを行い実行可能なプログラムを生成する作業）などを（半）自動化してくれる。
ビルドしたコードは、本番稼働サーバーへのプログラム展開（デプロイ）されるが、車載ソフトウェアの場合は、いったんHILSシステムで機能テストを行いECUに実装される。
重要なのはソフトウェア設計のコア部分の手の内化
ゾーンアーキテクチャやスマートアーキテクチャの次には、クラウドアプリケーションとCANネットワークのECUプログラムを統合する統合ECUやビークルOSという概念が控えているが、いずれにせよ車両開発に占めるソフトウェアの比重は大きくなる。
繰り返すが、相対的な比率が変わるだけでハードウェアの機能や品質は変わらない。吉澤氏の言葉を借りれば「ソフトウェアでハンズオフ機能を実現しても、ハードが安全でなければドライバーはハンズオフしてくれない」のだ。ハードウェアの品質を担保した上で、ソフトウェアを実装していく必要がある。
ハード・ソフトの信頼性を高めるため設計・開発工程に、いままで以上にソフトウェアの要件定義や設計が重要になっていく。そのため、各社はエンジニアの強化、ソフトウェアの内製化を進めているが、最後に吉澤氏は次のように語る。
「複雑化するソフトウェアのすべてを内製することは現実的ではない。重要なのは、車両システムやサービス全体設計の手の内化である」
からの記事と詳細 ( 変貌するE/Eアーキテクチャと内製にこだわらない手の内化…日産の車両開発モデル - レスポンス )
https://ift.tt/3w3blUu
