序文
- 自動運転を社会実装として成功させるためには、なすべきことが多い。
- 自動運転の分野には多くの会社が参入している。
- しかしながら、自動運転を社会実装として実装し切るには、各社の取り組めている範囲が足りないように拝見する。（それは、必要なことがあまりに多岐にわたるので、しかたがないことではあるのだけれども。）
- 自動運転には、無関係な人物が、無責任に書いた駄文である。
自動運転のさまざまな階層
- 自動運転をサービスとして行う主体としてのアプローチ
- 自動運転を車両として提供するアプローチ
- 自動運転の要素技術（部品とソフトウェア）を提供するアプローチ
- 自動運転の開発のために必要なデータの提供に徹するアプローチ
あなたの会社はどの階層で成功しようとしているだろうか。
成功して残る会社
-
自動運転で利用させる機械学習の推論を実施するエッジデバイスの会社
- エッジデバイスの開発会社は多くない。
- 要素技術を開発する会社は、それらのエッジデバイスのうえでの競争をしているので、どの会社の要素技術であっても、同じエッジデバイスが生き残る。
- 汎用型のエッジデバイスの会社、自動車に特化したエッジデバイスの会社がある。
- 例：Ambarella
- Hailo
- この分野の会社が強みを発揮するためには、自社のエッジデバイス上にアプリケーションを作る企業をサポートすること。
- そのため、オープンソースのアルゴリズムを、自社のエッジデバイスに移植して使いやすい状況を作ることをしている。
- 特定の用途でのエッジデバイスを目指す場合には、標準で用意されているセンサへのIOが重要になる。
- エッジデバイスが使われる分野での通信プロトコールのサポート。
- エッジデバイスで勝負するには、
- せめてリファレンスデザインの品質・提供する学習済みモデルの品質が高くないと、利用者が寄り付かない。
- 十分な数の利用者を獲得するようにしないと、そのエッジデバイスを継続できない。
- NVIDIAのエッジデバイス、IntelのOpenVinoに対して優位を作れないならば、存在価値はない。
-
自動運転で利用するセンサを提供する会社
- 自動運転のためには、各種センサが必要になる。
- 自動運転で利用可能なセンサは、複数のアルゴリズム開発者が同様に同じセンサを利用する可能性が高い。
- Automotive HDR Camera C1 / C2
- トンネル出口付近での画像の白飛びは、認識を不可能にする。
- ITD Lab Intelligent Stereo Camera
- イメージセンサで要求される解像度・フレームレート・暗い環境での特性などは似通ったものになる。
- 特徴的なセンサを提供する会社
- 例：偏光イメージセンサ 記事
-
自動車メーカーに、トータルのシステムとして提案できる会社
- 自動車メーカーは、自動運転の性能をトータルとして責任をもってくれるパートナー
- 自動運転システムの下位のコンポネント（例：信号機検出）について、自動車メーカーは直接関与することはないだろう。
- この階層では、必要な認証を取得できることが求められる。
- 複数のコンポーネントと能動デバイス、他の車両・人物・環境を含めた環境での性能を引き出すことが必要になる。
- MATLAB/Simulink 環境などのように複数のコンポーネントでシミュレーションすることも必要になる。
-
一つの機能について、センサ・アルゴリズム・推論・制御の組み合わせをデバイスとしてサービスを提供できる会社
- 一つの価値を十分に複数の会社に、明確な機能と品質で提供できる会社
- 一つの明確な価値を車両メーカーに直接提供できる
- MobileEye のような会社がそれにあたるだろう。
-
自動車の利用形態（バス・タクシー・長距離トラック・短距離トラック・特殊車両）に特化した機能を提供する会社
- 利用される自動車の種類ごとに必要な機能は違ってくる。
- 高速道路での走行が多い長距離トラックの場合、その機能に特化することで利益を引き出しやすい。
- 大勢の人を乗せるバスでも、十分な経験を持ったドライバーを確保できないことがある。
- そのような状況でも、安全を確保しやすくすることに価値がある。
-
自動運転を推進するための実証実験に特化する会社
- 自動運転を実際に公道で走らせるようにするには課題が多い。
- 当分は、ドライバが常に運転できるように控えている必要がある。
- このような会社が、開発中のシステムを評価するためのデータを取得して、開発会社に提供する形態が考えられる。
- 実証実験をしている会社にしても、実証実験どまりでもOKと考えている会社と、本当に事業化をしたくている会社がある。
実証実験中のデータをどの程度取得しようとしているのか、
それらを元に開発にどの程度フィードバックをしようとしているのかは
会社によって温度差がある。
実証実験についても、磁気マーカーを埋め込んだ路上を想定するのもある。
それらによって適用範囲が違ってくる。
それらの違いを調べたうえで、のぞむことだ。
-
保険業務のほうから自動運転技術の普及をはかることで、保険の分野で利益を確保していくアプローチ
システム構築者の立ち位置
- 下位のレイヤーの機能が何かの理由で故障することを想定する。
- 部品が壊れる・断線する・ソフトウェアモジュールが不可解な動作をする。
- そういった状況の中で、事故を防ぐソフトウェアを構築する。
予想される状況
予想：個別の物体検出アルゴリズムなどは、２〜３年の短期間で入れ替わる可能性高い。
- いくつかの機能は、その入出力が標準化される必要があるだろう。
- 理由：明確な機能は、その入出力が標準化される宿命を持つ。例、イメージセンサは標準化されている。
- 理由：標準化された入出力で、他のアルゴリズムを置き換え可能なことが求められる。
- 理由：標準化された流儀に従わないものは、評価するのが難しくなるので、検討の選択肢から外されてしまう。
予想：入出力が明確な画像認識技術だけでの勝負は、一番置き換えがされやすい、一番のレッドオーシャン。
- それ以上の価値を実装しないことには、生き残れない。
- 例： 一般物体検出をいまの処理中の画像についてするのではなく、時系列のなかで、遅延をキャンセルする程度に、未来予測を取り入れること。
- 例： 人が運転をするときに注視を向ける領域に対して優先的に認識の機能を割り当てて実現する機能。
画像認識単独の部分も、車種が変わる・カメラ取り付け位置と向きが変われば、性能が変わってしまいやすい。
- 乗用車の座席の高さと、トラック・バスの座席の位置は異なる。
- それに対応して、カメラの取り付け位置も変わる。
- そうすると、見え方が変わってくる。
- 静止している条件で２ｍ前の人を見ても違った見え方になる。
- 違った見え方になるということは、それぞれを同時にカバーする学習を作ろうとしたら、両方を同時に学習させるか、それぞれの学習を実現するということだ。
- 白線の検出のアルゴリズムでの学習も、車種の違いの影響を受けるだろう。
- 自車が着目すべき信号機の見える位置も相対的に変わってくる。
これらのことに注意してほしい。
付記：
- カメラ取得画像を、異なる取り付け位置での画像に変換する手法も研究レベルで存在している。
[UniSim: A Neural Closed-Loop Sensor Simulator]
(https://openaccess.thecvf.com/content/CVPR2023/papers/Yang_UniSim_A_Neural_Closed-Loop_Sensor_Simulator_CVPR_2023_paper.pdf)
完璧な機能をでなくても、利用する価値を引き出す社会実装を実現する。
- 不完全な機能なりに、実現できている範囲から利用する価値を作り出すこと。
事業として収益があがって、横展開が可能になること
認識技術より上位側の階層のアルゴリズムが難しい
- 自動運転の難しさは、未来予測をしてあるべき選択を常にし続けることにあると思う。
- 例として、高速道路での自動走行を考えれば、車線保持、前方車両との適切な車間距離の保持などがあるだろう。
- ドライビングの制御をどうするのかを含めて、性能の確保をすることが必要。
- センサの故障、ソフトウェアモジュールのバグ、あるユニットの機能停止、そういったことが起きたときにどうするのかを含めて、上位層のアルゴリズムが構築されなくてはならない。
- 自動運転に関わる利益は、実装上の難しい部分で、容易に他社製に置き換えられない部分に集中するだろう。
自動車内部の部品の規格・認証への理解が必要
- Mitsubishi SpaceJet(MRJ) の失敗は記憶に新しいだろう。
予想外の状況が起きても自分たちのビジネスが生き残れるアプローチを
- ビジネスとして生き残るためには、生き残りやすいアプローチをすることが必要だ。
- 自分の立ち位置が、他者にとって必要とされやすい立ち位置になることが大事だ。
- 簡単に、競合の会社の製品によって置き換えやすい立ち位置は考えものだ。
- 企業間の競争だけではなく、国家間の競争も影響している状況のなかで、私達はビジネスをしている。
- 国家の作る法律の一つで簡単に状況は変わってしまう世の中にいる。
- Transformarベースの技術は、確実に画像認識分野も変えてきている。
必要なこと
- 完全なものができる以前の段階でも、開発の継続に必要な資金を獲得し続けられること。
- 完全なものができる以前の段階でも、部分的に利用できる条件を見つけること。
必要な技術的な要素
- カメラの特性と３次元の空間的な対応付けとを簡単にすること。
- 検出・追跡の結果をその３次元の空間的な対応付けること。
- 各種センサの時刻の位置の整合性を確保すること。
- 車両のステアリングなどの操作の情報も時刻情報付きで受け取ること。
- 自車の情報を元に、外界の解釈に利用可能にすること。
- 短時間先の未来を予測できるようにすること。
- 限られた計算リソースの中で、優先的の計算すべき内容を明らかにすること。
- などなど
うまくいくために必要と私が思っていること
- 実用になるシステムを作り上げるために、自社の製品を使ってくれる企業とともに成功すること。
- ある水準のものができたら、それをベースにより良いものを作るのに、必要なデータの収集・アノテーションのコストを下げること。
- 価値が、認識それ自体ではなく、認識によって生じた行動によって生じることを前提に、認識後のアルゴリズムを開発して活用すること。
- そのためには、遅延を減らすだけではなく、適度の未来予測が重要なことを忘れない。
- ある出来事と次の瞬間での判断をするためには、単純なCNN・単純なRNNでは不十分であることを理解すること。
- どのような方策でクルマを操作するのかを設計するにあたって、どういうアプローチでは失敗してしまうのかを常に意識し続けること。
- 今利用できるセンサ・アルゴリズム・計算リソースのなかでのバランス感覚を磨くこと。
- 検出・追跡を行う際に、車両検出・レーン検出などを行う際に、CPU,GPUでの演算コストを減らす必要があるかもしれない。
- 同一の入力フレームに対して、車両検出などの物体検出と別にレーン検出を実行させるよりは、同じ入力フレームの入力に対して、車両検出などの物体検出と同時にレーン検出をも出力するCNNを作る必要があるかもしれない。
- そうすれば、CNNの初期の層は共通になることで、演算量を減らすことになる可能性はないだろうか。
海外市場を含めて生き残れる戦略の必要性
- 海外市場に対応していない（対応する予定のない）自動運転が、世界市場の中で残れることはないだろう。
機械学習のアルゴリズムは入れ替わり続ける。評価データは生き残る。
- 自動運転の機能の一部への評価データの重要性。
学習・評価用のデータ形式の標準化の重要性
- 自分たちが有用なアルゴリズムを新規に開発したとしよう。
- そのときに、新規のデータ形式がアノテーションとして必要になったら、必ず、そのデータ形式の学習用・評価用のデータ（の一部）を公開しよう。
- そして、そのアルゴリズムの利用者が使って評価してくれる状況を作っていこう。
- 1社の内部で必要な学習データを集めて、学習をしているだけでは、世界の開発の速度に追いつかない。
- 先人たちがデータ形式を標準化してきたおかげて、同じデータを別の機械学習に使い回すことができている。そのような仕組みを作っていかない限り取り残されて廃れてしまう。
優位な状況を失ういろんな方法
推論エンジンの場合
- 入力の解像度・フレームレート・カメラ入力の数が、求められている水準の上昇に追いつかなくて取り残されること。
ロジックを固定した推論エンジンの場合
- ロジックを固定しているハードウェアのアクセラレータを搭載しているチップがあった。
- このチップの場合には、深層学習以前のチップで期待されたものの一つだったが、物体検出のアルゴリズムが深層学習で性能が向上したことで、従来のアルゴリズムを使うメリットはなくなってしまった。
学習の更新をおろそかにすることで、価値が低下してしまう。
- ナンバープレート認識において、ご当地デザインのナンバープレートが導入されたことで、それ以前の学習データでのナンバープレート認識のライブラリは、価値が低下してしまった。
- これと同じことは、車両検出・歩行者検出においても起きる。
車載分野で知っておかなければならないこと
モデルベース開発
MathWorksモデルベースデザイン
HIL（Hardware-in-the-Loop）テスト手法
SIL（Software-in-the-Loop）シミュレーション
上の図は、以下のwebセミナーからの抜粋。検出・localization は、全体のなかのほんの一部にすぎないことがわかる。
https://jp.mathworks.com/videos/highway-lane-change-1624264695139.html
オープンソースでのアプローチ
クルマの自動運転の開発内容をオープンソースとしようとする試みがある。
オープンソースの自動運転OS「Autoware」で世界をリードする ティアフォーが「TECH PLAYER OF THE YEAR賞」を受賞
https://tier4.jp/opensource/
自動運転技術の開発会社の今後に関する私の予測
- 事業を継続できる会社は多くない。
- 技術の他社優位性を示せる分野がない会社・チームは廃れるしかない。
- 他社優位性を示し続ければ、そのチームはどこかに合流できるかもしれない。
- 特許は必要。
- データセット・ノウハウを展開しやすくしておくこと。
見返りの得られる開発をするための問題のサブセット
例：高速道路での長距離トラックの走行を自動化する。
-
路上に人がいることが少ないことによる人身事故の可能性が減る。
-
高速道路では走行パターンが、一般道よりも単純化できる。
-
自動運転によるコストに対する見返りが得やすい。
-
自動運転を投入したシステムの駆動時間が少ない個人用の乗用車では、見返りが得にくい。
例： 車両専用とすることによる単純化
「気仙沼線BRT「完全自動運転」導入へ レベル4取得目指す、自動運転区間も拡大」
あなたの会社の取り組みが、無駄にならないようにすること。
- 調べてみよう。
- EyeSight の場合には、システムの上位層でどのような形で品質を確保しているのか。
- MobileEyeはどのようにして市場にアプローチしたのか。
日本学術会議 自動運転の社会実装と次世代モビリティによる社会デザイン検討委員会
経済産業省 自動走行ビジネス検討会
Mathwoks MATLAB/Simulink による自動運転・ADAS 開発
機能安全
「自動車用機能安全規格ISO26262の紹介」
「安全規格の紹介 ISO 26262(車載用機能安全)」
不安になること
- 自動運転に関わる開発が、従来型のヒエラルキーをもった会社での開発になっているのを見る。
- ガラケーでの開発スタイルと似ていることに不安を感じる。
ヒエラルキー型の開発の問題点
-
上位側が十分な要件定義ができないことがある。
-
上位側が設定するAPIのインタフェースが適切でないことがある。
-
下位側の実装する開発依頼の契約条件に問題のある場合がある。
- 人月をベースとする開発
- 受諾側企業にとって、品質や生産性への動機づけが希薄になりやすい。
- 「木村岳史の極言暴論！」「人月商売のIT業界は「プロとは言えない連中ばかり」、仕事が楽しくないから当然だな」
-
下請け型の開発スタイルでは、上流側へのフィードバックがされにくいという問題がある。
-
自動運転の達成という目的と、下位のモジュールとの関係をどう調整させるのかが、アイディアをぶつけ合うことがことが、下請け型の開発スタイルではなくなってしまうのが問題だ。
-
下請け型の開発スタイルでは、開発委託期間という時定数が、開発速度を決めるものになって、改良のためのフィードバックをそれより早く回せなくなる懸念がある。
-
次のような求人案件で求める必須条件と待遇の格差には驚きを隠せない。
「判断・制御アルゴリズム、全体システムの研究開発【自動運転システム開発】」の求人が画像AI分野の相場を反映していないのが驚きだ。
＜応募資格/応募条件＞
■必須条件：
・車両制御システム開発経験
（中略）
＜予定年収＞
400万円〜750万円
＜賃金内訳＞
月額（基本給）：210,000円〜
学会・研究会・勉強会に参加しよう（いうまでもないことだが）
- デジタルカメラに顔検出が加わったという変化にくらべて、自動運転への変化は、1000 倍以上も不雑さが高い課題になっている。
- デジタルカメラの顔検出という課題に対して、格段に複雑さがあがっている。そのため、世の中での技術の進歩を取り入れて開発していくことが大事になる。また、開発戦略を定期的に見直すことも必要になる。
- 自分たちに不足しているピースの技術を、自分たちの組織での開発に取り込んでいくことが必要になる（技術提携や技術者・研究者の取り込みなど方法はいろいろだろう。）
ぜひ、日本の会社が生き残ってほしいものだ。
読んでほしい本
「バーチャル・エンジニアリング-周回遅れする日本のものづくり」
「バーチャル・エンジニアリングPart2 危機に直面する日本の自動車産業」
「バーチャル・エンジニアリングPart3 プラットフォーム化で淘汰される日本のモノづくり産業」
「バーチャル・エンジニアリングPart4 日本のモノづくりに欠落している“企業戦略としてのCAE”」