SDVは日本の車載ソフトウェア開発の慣習を変えるチャンスになる：SDVフロントライン（2/3 ページ）

100年に一度の変革期にさらされている日本の自動車業界が厳しい競争を勝ち抜くための原動力になると見られているのがSDVだ。本連載では、自動車産業においてSDVを推進するキーパーソンのインタビューを掲載していく。第2回は、車載ソフトウェア標準化団体であるAUTOSARの日本地域代表を務める後藤正博氏に話を聞いた。

[朴尚洙，MONOist]

SDV対応では車両外とデータをやりとりするAutomotive APIを標準化

MONOist　SDVが注目を集めていますが、AUTOSARではどのように対応していますか。

後藤氏　AUTOSARでは、当初から行っている制御システムなどの車載ソフトウェア向けのCP（Classic Platform）と、自動運転技術などへの対応を見据えたAP（Adaptive Platform）、CPとAPの共通項目であるFO（Foundation）という3つの領域に分けて標準化活動を行っている。さらに、SDVへの対応という観点で、車両外とデータのやりとりを行うのに必要なAutomotive APIの標準化にも取り組んでいる。

　自動車業界がSDVに向かっていく中でも、AUTOSARはあくまで車両内のプロセッサやコントローラーを対象にした標準化活動が中心になる。ただし、クラウドなど車両外にあるシステムが、車両内部にあるデータとのやりとりが必要になる場合にそれを可能にするのがAutomotive APIだ。もちろん、車両外と情報をやりとりするといっても、センサーインタフェースの標準であるISO 23150などの場合はAUTOSARとしてもAutomotive API以外での対応が必要になる。

　Automotive APIは、COVESAのVSS（Vehicle Signal Specification）など他の車両APIの規格を吸収できるようなコンセプトを想定している。単に車両外の情報を取ってくるだけではなく、車両外と車両内での情報のやりとりも可能にしなければならない。車両内のデータをどう集めてくるか、どういう精度で集めるか、どのようにAPIに渡すかなど、データの取りまとめ方の粒度が重要になってくるだろう。

　また、2025年9月の施行が予定されている、コネクテッド製品におけるデータ収集に関する法規制となる欧州データ法を意識すると、車両内のデータを集約してまとめるデータベースなども必要になってくるだろう。欧州では、車両から直接情報を取るのではなく、ニュートラルサーバに集めてからAPIを介して情報を取り出すというコンセプトを検討している。自動車メーカーとしては本来は直接データを取りたいが、自動車メーカー間で互いにアクセスさせたくないデータも存在するため、第三者的なニュートラルサーバに集めてデータにアクセスするという方式が想定されている。

　AUTOSARの標準化活動は、これまで車両内のことに集中していればよかったが、SDVによってそうも言ってられなくなっている。SDV関連の取り組みは、状況が完全に整理されているわけではないが各所で活発な活動が進んでいるので、それらをしっかり見極めて対応していきたい。

MONOist　日本におけるAUTOSARの導入状況をどのように見ていますか。

後藤氏　AUTOSARの存在は既によく知られており、その上で各社が自社の状況に合わせてうまく使っている。既存の車載ソフトウェアに対する品質保証プロセスとの兼ね合いもあるので、緩やかに導入を広げているというイメージだ。日本の自動車産業が品質を担保することを重視している以上、当然のことだろう。

　AUTOSARの導入が進んでいる欧州の車載ソフトウェアがモジュラー型であるのに対し、日本はすり合わせ型になっている。ただソフトウェアの品質面で言えば、2003〜2006年頃は日本の方が品質が高かった。近年はAUTOSARを用いたモジュラー型車載ソフトウェアに対応するツールが進化していることもあり、欧州の車載ソフトウェアも品質面で問題はなくなっている。

　日本の車載ソフトウェア開発は、ホワイトボックステストを重視しておりコードを1行1行見て本当に大丈夫かというようなアプローチを取っており、これは過度なすり合わせになってしまっている。これから日本が目指すべきなのは、モジュラーベースのすり合わせ型だろう。

　高性能車載SoCを使ったハイパフォーマンスコンピューティングが自動車に入ってくると、ソフトウェア検証プロセスもより複雑になる。いわゆるミックスドクリティカリティーをどのように担保するのか。ISO 26262のASILのレベルでECUを分割するのか、統合ECUとして高性能車載SoCの力を使い切るのか。今、車載ソフトウェアのアーキテクチャをどのようにすべきかの岐路に立っている。確かに集中と分散の波はあるが、やりたいことができるアーキテクチャを選ぶべきだ。アーキテクチャに一度載せてみることで分かることもある。今後は、ネットワークの帯域は広く、プロセッサは大きく、データは複雑になる。その状況下で、やりたいことをどうやって実現するのかを検討していかなければならない。