⁠

⁠コラム「自動車業界よもやま話」では、自動車業界で働く人の視点から、自動車関連のさまざまな話題を取り上げていきます。  

Xin1を実現するために解決すべき課題は多くあり、統合する機能が増えれば増えるほど統合の難易度は増していきます。

今回は解決すべき課題の第1弾として、故障時の影響範囲やソフトウェア統合などについて解説します。

1カ所の故障が複数の機能に影響するXin1

Xin1では、従来であれば複数の部品が担っていた機能を1つの部品に集約します。その結果、集約した部品の故障箇所次第で、複数の機能が同時に使えなくなってしまうリスクがあります。完全自動運転に向けて、ドライバーが介入しない状況を増やしていこうとしている中で、1つの故障で複数の機能が使えなくなってしまうのは致命的であり、安全性に大きな懸念が生じます。

そこで、Xin1部品の、どの部分に故障が生じたとしても、最低限の安全性は確保できるように、電気的もしくはメカ的な冗長化設計を行うことが重要です。また、故障診断を行う機会を増やし、診断時間も短縮することで、故障の影響を最低限に抑える必要があります。

どの部品の冗長設計を行えばよいか、新たな故障診断を追加する必要があるかどうかは、ISO26262に定義された、いわゆる機能安全対応のFMEAやFTAがクローズできるかどうかで判断するといいでしょう。複雑な部品であればあるほど、FMEAやFTAの作成には時間がかかります。また、レビューをするたびに観点がずれてしまうリスクがあるため、着手時点で観点を定め、途中でずれが生じないように注意します。

ソフトウェアをどう統合するか

複数の機能を1つの部品に統合するため、従来は分割されていた複数のソフトウェアを統合する必要があります。ソフトウェアの統合には大きなハードルがあります。例えば、機能ごとの演算順序はどのように決めるのか、ソースコードの記載ルールはどのソフトウェアに合わせるのか、ソフトウェア内の各モジュールの役割分担はどのように決めるのか。このような課題を一つ一つ調整する必要があり、統合する機能数が増えるほど統合の難易度は高くなります。

構成の異なるソフトウェアの統合を進めるには、車載ソフトウェアのためのアーキテクチャ規格であるAUTOSAR Adaptiveなどによるソフトウェアの仮想化・分離の考え方を取り入れることが重要です。また、OTAの対象をモジュール単位に限定するような対応を行うことで、ソフトウェアアップデートの際に他の機能への影響や全体の開発規模を抑えつつ、最新の機能を搭載することができるでしょう。

複数企業が絡んで開発することの悩ましさ

Xin1で統合する部品の開発には、複数のサプライヤが携わっている場合がほとんどではないでしょうか？ 開発の主導をどの企業が行うのか、部品ごとに異なる開発のプロセスや社内のイベント対応などをどのように行うのかなど、統合部品の開発においては担当企業が複数あることで、多くの課題が生じます。

Xin1は、中心となる機能を担うサプライヤが主導する場合もありますが、統合部品数が多くなる場合にはOEMが主導して垂直統合していくのが望ましいです。OEM主導のもとであれば、複数のサプライヤが並列に開発を行うことが可能ですし、サプライヤ間での機密情報のやり取りもOEMが情報を集約することで最低限に抑えられます。

製造・整備の柔軟性が低下する

統合する機能を増やすことで、Xin1部品の構成は複雑になりサイズも大きくなります。その結果、部品の組立は難しくなりますし、点検や交換にも時間がかかるようになるでしょう。一体化によるメリットを失ってしまうかもしれませんが、可能な範囲で一体

化部品のモジュール化を進め、モジュールごとに生産やメンテナンスをできる状態にすることで、部品統合のメリットとデメリットのバランスを取れる可能性があります。また、故障診断機能を高度化しビッグデータを活用することで、点検や交換時の部位特定精度向上や交換頻度低減を実現できるかもしれません。

Xin1実現の課題をどう乗り越えるべきか

Xin1の実現は大きなメリットがあるものの、従来とは異なる部品設計の考え方を取り入れ、企業間の役割分担や責任分担を変えることも必要になります。ある程度規模が大きく、複数の機能を担えるメガサプライヤやOEMが主導しなければ、開発に時間がかかるばかりで高性能なXin1の製品を開発することは難しいでしょう。

次回は、Xin1で生じる課題の第2弾を紹介します。