湘Nyan!のブログ一覧

テスラがFSD(自動運転)のベータ版をアップグレードしたら原因不明のファントムブレーキ(障害物がないのに急ブレーキがかかる)の発生回数が増えたとのクレームが数多く発生して、とうとうリコールとなった。対策はロールバック(元のバージョンに戻す)でした。 イーロンマスクはOTAで修正するからリコールではないと主張したが監督官庁にそんな主張が通るはずかない。

事故動画を見るとFSDはやめとけと言いたくなります。15000USドル払ってぶつけられたらたまらない。

完全自動運転には もう少し時間が必要ですね。


【オマケ】
そもそもクルマ用ソフトウェアでベータ版ってのが理解できない。しかも有料、、、顧客を使ってリアルワールドで実験に参加しているのだからテスラが参加料金を払うべきでは？

ヒョンデのIONIQ5の車載ソフトウェアに問題があることは間違いないが、なぜそうなるのか？ 対策はどうすれば良いのかを簡単に書きます。

クルマには複数のコンピューターが搭載されユニット間はシリアル通信を行っています。個々のユニットは独立して動いてますがアクチュエータを動作させるサブコンピュータはメインユニットの指令に従って動作します。問題は自分の処理が忙しくて通信データの処理が後回しになるときがあること。

忙しいのは下記の場合
①起動時
②終了時
③特別な処理をしているとき


通信に対する処理が追い付かないときはバッファにデータを貯めておきますが、あまりに貯まるとオーバーフローしてしまいます。パソコン用のソフトウェアではオーバーフロー検知を行っていてスタックメモリが不足すると全ての処理をストップさせます(ランタイムエラー)。windowsやMACでアプリが固まるのはほとんどこのせいですね(タスク間通信の不整合)。組み込み機ではオーバーフロー検知は処理が重くなるので搭載していません。このためスタックオーバーフローは暴走に直結するので発生させてはいけない。

C言語でコーティングするとスタック領域を意識することはないのですが、現実には物理メモリの領域には制限があるのでオーバーフローしない仕組みが必要です。

言うは易し行うは難し、、、これを乗り切るのが車載ソフトウェア開発者の責任です。現在このコーディング作業を管理できるツールも仕組みもないので全てが担当者の腕にかかって来ます。モジュール単体でのテストでは問題が発見できないのでエンジニアの想像力だけが頼りです。

最近のEVはソフトウェア容量(ソースコードサイズ)が大きいので開発に関わる人は100人を越え、しかも複数の外注ソフトウェア業者が関わっている。このためすみからすみまで目が届かないし、開発時期が異なるモジュールを組み合わせているため責任分担も不明確。複数の開発言語(java、アセンブラ、C++)やツールの存在も悩ましい。
かように管理は非常に難しいので開発担当者の質の高さが最重要です。

テスラが成功したのは質の高いシステムエンジニアをシリコンバレーで直接雇用したからだろう。賃金が安い関連会社に開発を丸投げのヒョンデには真似ができないのは自明の利です。

【オマケ】
テスラを買うのが対策かな。知らんけどw