リモートスタートみたいな機能があって、これらの機能があんまりうまく設計されてないんじゃないかなって思う。

新しい車って、パフォーマンスに影響するアップデートがあるみたいだね。ギアのシフトの仕方とか。

情報を交換する限り（駐車センサーの音を聞くために音楽をミュートすることとか、次の給油のためにバッテリーや燃料の状態をリクエストすることとか）隔離は完全にはできないよね。

僕の車のインフォテインメントシステムはサスペンションに変更を加えられるんだ。ストリートモードからトラックモードに切り替えられるし、タイムを計るためのローンチモードもある。バレーパーキングモードにすると、速く走らなくなるんだよね。もしバレーパーキングモードのパスワードを忘れたら、ディーラーでは解除できないからすごく高い代替品を買わなきゃいけないって言われた。

君は最初に、これがインフォテインメントシステムのOTAアップデートだって前提を持ってて、その後この事件は起こるべきじゃないって結論に至ってるけど、その前提が問題なんだよ。これは車両のOTAアップデートなんだ。インフォテインメント、ECU、ECM、TCM、BCMをアップデートする能力がある。複数のメーカーが安全性、信頼性、パフォーマンスの重大な欠陥を修正するリコールを出せてるのは、コアの車両コンピュータシステムをアップデートするOTAアップデートがあるからだ。このOTA＝インフォテインメントっていう考えはどこから来たのか不明だね。2025年にはほとんどのメーカーがこれができると言ってもいいよ。

コストの問題だよ。同じ理由でダッシュクラスターやインフォテインメントシステムが全部モニターになったんだ。アナログゲージよりも実際にずっと安いんだよね。ソフトウェアは「書き直さず、常に再利用する」っていう有名なクソみたいなパラダイムの上に作られてて、その結果、全てがどう協力するかなんて考えずに適当にパッチが当てられてる。今やハイブリッドや電動ドライブでは、モーターコントローラーは自分のソフトウェアを動かすパッケージで、車の他の部分とインターフェースを取るんだ。OTAアップデートはそのファームウェアを上書きできる。ほとんどの問題を避けてるメーカーはトヨタだけで、彼らはかなり前からハイブリッドをやってるからね。他の会社はこの道を始めたばかりで、追いつくためにソフトウェアの深掘りをする余裕がないんだ。

なんで走行中にアップデートが行われるの？

もう孤立してないよ、テスラがこの前例を作ったから、みんなが真似しようとしてる。ボルボも同じ問題を抱えてる。

OTAアップデートで俺のタホのインフォテインメントシステムがブリックされたことがある。今はバックカメラが標準装備だから、それが使えなくなった。ウィンカーを使ったときに聞こえるカチッという音も完全に無音になった。修理に約2,000ドルかかったけど、保証は効かなかった。いいことだね。今後の「アップデート」は無効にしたよ。

テレマティクスのアップデートだったんだよね。

ラングラーの改造におけるソフトウェアハッキングの側面は、全然枯れてないと思うよ。例えば、https://www.jlwranglerforums.com/forum/threads/jeep-hacking-... みたいなのがあって、これが商業化されて https://www.zautomotive.com/products/z_tzr_jlm になったらしい。ただ、ヘッドユニットのファームウェアを破った人がいるかは分からないけど。

ジープって、信号待ちのときにインフォテインメントのポップアップ広告が流れる会社じゃなかったっけ？オープンソースのOSに置き換えるなんて、彼らは絶対に望んでないと思うよ。

毎年新しいデバイスが出て、プロのチームが常にアップデートをしてる。でも車は新しいデバイスを手に入れることができないから、一貫性が必要で、ちゃんと動き続けなきゃいけない。しかも、少人数でそれを実現しなきゃいけないんだよね。

俺はこの接続されたインフォテインメントシステムのソフトウェアを作ってる会社で働いてた。そこのコストカットは徹底してて、RAMもCPUも最小限、画面もひどいものだった。高級モデルでもそうだったよ。車のラジオはいつも安物だってことを忘れちゃいけない。

最近、比較的新しいメルセデスにAndroidフォンをBluetooth接続してテストしてみたんだけど、「ラグジュアリー」ブランドなのに、メルセデスのインフォテインメントソフトウェアには1時間のテストで少なくとも5つのバグを見つけたよ。特にバグを探してたわけじゃなくて、Bluetooth接続のうまくいくパターンをテストしてただけなのに。Androidフォンは完璧に動作してたけど、見つけた問題は全部、誰かが気にしてれば防げたと思う。車自体は他の面ではしっかり作られてる感じだし、問題はエンジニアリングの能力じゃないと思う。（ちなみに、メニューの表示やスクロール、検索が遅すぎるセットトップボックスのGUIも、プログラム次第で10〜100倍速く動くハードウェアで動いてるのを知ってるから、余計にそう思う。）

そういうのは、アクセスが難しい場所にあって、稼働時間の要件が厳しいデバイスでやってたよ！工業用ルーターやプロトコルコンバーターとかね。すぐに元が取れると思うよ。そういうデバイスのために誰かを派遣するのは高くつくからね。

確かにいい指摘だね。これを怠ることで、ジープが正当な訴訟にさらされる可能性があるか気になる。

更新でいくつかのものが壊れたことはあるけど、Fedora Atomics/ublueに移行してからは、戻れないシステムにはなったことがないよ。

それは2桁のUSDデバイスで、5桁や6桁の電気SUVじゃないよね。これってコスト削減策なのかな？その価格帯で、NANDのサイズを倍にするのは車両の総コストのほんの0.何パーセントにも満たない。単に能力や優先順位の問題かもしれない。もしコスト削減なら、あるPMが締切に間に合わせるためにスプリントからストーリーを削除した可能性が高いと思う（異議が出なかったか無視されたか）。NANDのサイズを削って1台あたり3ドル節約するために、エンジニアリング分析をしたとは思えない。編集：実際、その手法は役に立たなかったと思う。問題は失敗したアップデートではなく、深刻なバグがあったことだから。OPからの引用：> バグのあるアップデートは、車を即座にブリックするわけではないようだ。代わりに、運転中に故障が発生する—これはもっと深刻な問題だ。

まあ、ポジティブな面で言えば、少なくともこれらの車両とは違って静止してたね。失敗したOTAアップデートの話はやめておこう。企業がそれを間違える方法はたくさんあって、全然笑えないから。

聞いた話では、自動車メーカーは1台あたり5ドル未満の価格変動に敏感らしい。これは1ドルに敏感な業界よりはマシだね。起こり得ることとしては、交渉者がA/Bアップデートを仕様に含めなかったか、1GBのOTAサイズでしかA/Bアップデートを指定しなかった可能性がある。いつものように価格を叩き合って、ヘッドユニットやECUのメーカーがストレージスペースを徹底的に削減してコストを下げたのかもしれない。A/Bアップデートにはまだ十分だったかもしれないけど、ソフトウェアの肥大化でアップデートがクリティカルな限界を超えたのかも。A/B/Aアップデート（Bは縮小されたアップデート専用のOS）を行えば安全なアップデートは可能だけど、それには開発時間が必要で、エンジニアは次の車両の開発に取り組んでいるべきだ。

IoT照明と自動車の両方で働いたことがあるから、比較するのは得意だよ。これは弁護として言ってるわけじゃないけど、大手自動車OEMは絶対的なBOMコストの最適化に敏感だよ、パーセンテージの増加に関係なく。これがブーツロットの問題だとは思わないけど、「ブリック」という言葉に関わらず。自動車のソフトウェアがどれだけ後れを取っていても、一般的に受け入れられているのは、車両が動いている間はアップデートが不可能だってこと。これは通常、複数のOEMで共有されるシステムによって強制される。状況は、ひどくバグのある新しいファームウェアのように聞こえる。スタランティスがそれをやらないとは思えないけど。自動車業界は時々、比喩的に言うと底を掻き分けているし、スタランティスは市場のトップの報酬で知られているわけじゃないからね。

追加で二つのポイントがあるんだけど、1) 車両の総コストは関係ない。重要なのは営業利益率だよ。総コストの0.5%の増加で、利益率が2%から1.5%に下がっちゃう。例えばフォードは営業利益率が2%なんだ。つまり、総コストが0.5%上がると、利益が25%も減るってこと！これってすごい数字だよね！それに、車メーカーは厳しい状況にあって、販売台数がかなり少ない（スマホは年間100万台、車は年間4万台）から、チップの要求も厳しくてコストが上がっちゃうんだ。2) ABのアップデートはいいけど、失敗したりソフトロックされることもあるから注意が必要だよ。特にスロットを設定する時に、良い状態の時と悪い状態の時でコードがどうなるかが重要だね。

他のデバイスも大体こんな感じだよね。例えば、すべてのAndroidデバイスやその派生品（これらの車の多くもそう！）は、ブリック化を防ぐために似たようなA/Bパーティションを使ってる。確かにアップデートのリスクは減るけど、完全にはなくならないよ。A/Bアップデーター自体がリスク要因だし、特にロジックが複雑で、同時に他の子デバイスもアップデートされる場合（車の場合はあり得る）にはね。その場合、単に2つの独立したパーティションを調整するだけじゃなくて、2 * Nのパーティションを調整することになるから、その半分は互いに依存してる。さらに、メカニズムの重要な部分は、成功したブート後に新しいパーティションが「良好」とフラグ付けされることで、アップデートが成功したことを示すフラグが設定され、バックアップパーティションが不要になることだよ。このロジックは（そして実際に）失敗することもあるから、失敗ポイントがこのチェックポイントの後に発生すると、もう手遅れになっちゃう。ほとんどのシステムでは、「すべて良好」のチェックポイントが早く発生することを望むから、例えば、すべてのユーザーサービスが立ち上がるのを何分も待ちたくないよね。でも、それは同時に、重要な失敗がそのサービスで起こった場合、チェックポイントを過ぎてしまうことを意味するんだ。

システムは、使用されるブートスロットを切り替えることで、自動的に前のバージョンに戻るはずだよ。でも、それが難しいんだ。私の経験では、A/Bブート設定は驚くほど一般的だけど、何か問題が起きたときに他のパーティションに戻るための実際のロジックがユーザースペースアプリケーションにないことが多い。これは、OTA中に誰かがプラグを引っこ抜くのを防ぐための防御策に過ぎなくて、ソフトウェアのバグには全く対処できてないんだ。

Googleで最初に出てくるいくつかのヒットが、テスラでこれが起こるって言ってるよね。https://teslamotorsclub.com/tmc/threads/tesla-software-updat...

これについては聞いたことがないな。テスラのグループやコミュニティ、フォーラムを10年以上フォローしてるけど。せいぜい、誰かがアップデートプロセスを始めて、急にどこかに行かなきゃいけなくなってイライラしてるって話を聞くくらいだよ（それに1時間かかるかもしれないし）。

正直、驚くことじゃないよね。ジープとステランティス/ダッジは全体的に品質管理がひどくて、電気設計も極めて悪い。熱心なファンコミュニティがあって、彼らは多くの欠陥をうまく誤魔化してるけど、正直言って、誰も彼らの車を買うべきじゃないよ。自分を損なうだけだから。

最近、家族と一週間の旅行をしたんだけど、グランドワゴニアを4台も使ったよ。それぞれが別の致命的な問題を抱えてた。

いつか古くなったJKを置き換えるために4XEラングラーが欲しいんだ。スペック上は素晴らしいし、トルクとパワーがたっぷり、タイヤが大きい割には燃費も悪くないし、町中を走るのに十分な純電動もできる。しかも、標準のラングラーのパーツもそのまま使える。ただ、クラシックなジープスタイルで信頼性が全然ダメで、PHEVの部分も彼らには複雑すぎるみたい。もし信頼性があったら、アメリカで一番売れてるPHEVになってたはずなのに、それを逃しちゃった。2026年のラングラー4XEの兆候もないし、グラディエーター版みたいにキャンセルされるかも…。

お悔やみ申し上げます。保証の下で使用損失のレンタルが適用されるか気になるね。

どうやってソフトウェアのアップデートが1. 車の運転中に行われることができて、2. 車両の電力喪失を引き起こすって確認したの？昔、自動車部品メーカーで働いてたけど、安全関連のコンポーネントのアップデートのリスクを防ぐためにいくつかの保護策があったよ。最もシンプルなものの一つは、UDSプログラミングセッションが車両の速度や運転モードに関連するエントリ保護を持っていることだね。

私の意見だけど、たまには混乱が起こることはあるし、最終的にはこういう大きな問題になるだろうけど、金曜日にこれを出すのは、重要なスタッフがいないから助けられないってことだよね。顧客やディーラーにこれを伝えられる人たちは、土曜日の朝6時にジープに乗り込むときには寝てたんだ。クラウドストライクのアップデートも金曜日の夜だったと思う。深刻なセキュリティバグでない限り、もっと良いQAテストのためにも、次の火曜日まで待てるはずだよ。金曜日のリードオンは業界全体でやるべきだね。

あなたのジープが動かなくなる（電力喪失、安全に路肩に行けなくなる）リスクがあるってことだよ、今これを書いてる間もね。これは異常だね。聞こうと思ったんだけど、本当に車が高速道路を走っている間に、車両の電力システム、つまりエンジンを停止させるって言ってるの？でも、聞く必要はなかった。記事にはそう書いてあるし、報告されている通りだね。> 代わりに、故障は運転中に発生するようだ—これはもっと深刻な問題だ。中には、家の近くで低速で起こった人もいるけど、高速道路の速度でパワートレインの故障を経験した人もいるって言ってる。すごいね。

こんなのありえないよね。数年前に自動車関連の会社を調査したとき、車両が静止しているかどうかを確認せずに更新してるって指摘したんだけど、みんな「そんなことで問題になるなんて思わなかった」って驚いてた。

これって、納期が何度も遅れたプロジェクトで、みんながその後の休暇を計画してるときに起こることだよね。時間に追われて、バイアスにかかって、壊れかけのコードにサインオフしちゃって、そのままプッシュした結果、重要なスタッフは飛行機に乗ってたり、携帯の電波が入らなかったり、休暇中でパソコンも持ってないから完全に記憶頼りで作業できない状態になってる。