“対策として通信速度設定を500kbpsから、250kbpsに書き換えた” なんか嫌な予感がする対処法だな？
回線細いなという点を突っ込めばいいのか、設定雑だなという点を突っ込めばいいのか
「対策として通信速度設定を500kbpsから、250kbpsに書き換えたということです」←応急処置だよな？そうだよな？
目を疑う気持ちで取りあえずブクマしたけどやっぱりこれ凄くまずい気がするよね…。更なる識者の意見待ち。
いろいろと謎が多すぎる。「通信が阻害」されたことで、車からパーキングブレーキが作動させられなくなる？／ネットワークには詳しくないけど、通信速度の設定、そんな、Tera Termでシリアル通信やるみたいな話なの？
「対策として通信速度設定を500kbpsから、250kbpsに書き換えたということです。」応急処置としては良いだろうけど安全に関わる部分なんだから速度が違っても安全が保たれるようにするべきなのでは
回線は太くしとけというのもあるが、フェールセーフ設計であるべきなのではと
いまの車は車両側にも基本的に自動ブレーキがついてると思うけどそちらは無効化されていたんだろうか？
え？ 必要な情報を車両側がちゃんと受けられるように車両側の通信設備を増強する方がよくね？ あと、想定外のことが起きたら、止まるように設計するのが基本だと思うんだが……。
無線ではなく車内で閉じたCANの話か? 送信し続けて輻輳しブレーキ命令が届かなかったって? 重大インシデントじゃん。初期化パラメータ直しただけで運行再開OKしていいレベルじゃない。絶対に輻輳しない手当てが必要だろ
早口すぎて聞き取れないみたいな感じなのかな
いま開発担当者の気持ちになってるんですけどね、ありがちな風景としては、無理筋な突貫開発と思いつつも不可能だと言える明確な理由は言えず走った結果⋯みたいな流れ。よくあることの想像ですけどね。
通信遮断されたら車側の自律自動停止処理が入っていないことに驚愕。あくまで管理側からの操作しなければならない設計は誰が許可したのかな？
動作チェックしてないってこと？ なにか昔のジョークでのマイクロソフトが車を作ったらみたいになってきた。
要領を得ない説明なので記者レベルに理解させるためにだいぶ情報が落ちてそう
“通信の設定ミスというのは、車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていたためでした。 対策として通信速度設定を500kbpsから、250kbpsに書き換えた”
自動運転はこの事故の前に別の不具合で動作停止中、手動運転に切替て自動パーキングブレーキが動作しなかった事例。エラーの錯綜でフットブレーキの信号が受信されなかったとのことだがRTOSじゃないのか...
詳しくないのですが、フェールセーフになってないように思えるのですが、理解不足でしょうか。
車の制御ってフェイルセーフが基本だと思ったけど、エラー時は端に寄せてパーキングブレーキかけるとかしてないんだ。鉄道系とか参考にしてないんか？
知ったかコメントする前に調べよう。既コメで既に指摘されてるが、これは恐らくCANで、250kbpsが基本規格のバスに500kbps流したら輻輳になるのITの知識あれば当たり前だって分かる、分からない方がむしろITとしては恥では？
エラーでわからんくなったらデフォで止まるってシステムじゃないんか
それ対策じゃねーから
CANプロトコルはすごいよくできてんだけどCANバス自体は中央制御する仕組みがないので一人でもアホの子がいるとこういう事態を招く。
こっちの方が少し詳しい。複数のシチュエーションで異なる通信速度を設定できるように見える https://subway.osakametro.co.jp/news/news_release/20250611_park_and_ride_bus.php
的外れなコメントが多すぎると感じるが、しかし、こんなプロジェクトで異常系を評価していないという事実と、基本制御の通信バスに割り込ませる設計なんだ(まあ多重化とかないか)という感想
この記事では良くわからんのでこっちを見た方が良い。 https://x.gd/W8T9M 自動運転システムが車両側システムにDOS攻撃(RSTフラッド？)した感じだけど、脆弱性として狙われそうな気もする
根本的にあかん。／対策するなら「問題発生時は自律で安全停止する」というものだし、普通は最初からそうなっていると思うが。自律停止できないレベルまでシステムを切り刻んでいるのならその設計はやめろ。
CANは調歩同期式なので、取り決めた通信速度以外ではそもそも受信できない(ビットを正しく解釈できない)。なので通信速度の修正は応急処置ではなく根本対策。ていうかテストしてないのかよ
『手動運転』という言葉の響きから機械制御な印象を受けるけど、自己報告書を読む限りはそもそもが電子制御だから手動操作も一つの通信でしかない、通信エラーで手動操作も受け付けないてのは直感に反するかも
ボーレートの設定ミスはともかく、異常時にブレーキの信号を阻害するのは怖い。車のパーキングブレーキも強制ONができるけどそういうのはなかったのかな。全然関係ないけど250kbpsってDMX512を彷彿とさせる。
デバッグと調整は実証現場でやるとか笑えんのやで。ホンマ議員や公務員の責任所在の明確化と厳罰化をせんと「税金おいしーれす」なゲスに食われるだけやからな。先ずはとっととスパイ防止法を立法せえ。
この記事だけ見れば、具体的な数値に言及して対策も記載されているだけに、そもそもの設計思想（フェイルセーフ）についてツッコミがたくさん来そうだが、そんなこと想定して記事を書いてるわけも当然ないよね。
よくわからんが高い通信速度に車両側が対応してなかったってことなのかな
鉄道事業者としておかしいと思わないんだろうか、鉄道だったら即非常ブレーキでしょこんなの
お粗末すぎる……万博(笑)
まあちょっと危なっかしい話だなとは思うけど、自動運転車の事故が過剰に報じられると導入が遠くなるので冷静に対応、静観しつつ、どんどん技術と制度を前に進めてほしい
無理矢理間に合わせたみたいな付け焼き刃感がすごい(ノ∀`)
設定ミスはまあしゃーないが（人的被害がないのは良かった）、作ったメーカーはフェイルセーフの概念がないのか？ / 絶対輻輳しない仕組み以前に輻輳したとしても安全側に倒す対策が必要。
対策が再発防止できてないような
CANバスのそのぐらいの事象でフォールトトレラントに出来ないシステムなのに市場に出してるんだ／自動運転システムは先進モビリティ（茨城県つくば市）が開発とのこと
とりあえずF-2戦闘機のFBW配線が逆に接続できて挙動が逆になるような設定ミス的ななつ?
外部の通信に運転を依存してるのおかしいだろ。データ量にもよると思う。操作側も連打してんじゃねーよ確認しろよバーカ。
“送信された大量のエラーデータで通信が阻害された結果、車側で、パーキングブレーキを作業するよう出した情報も阻害されて伝わらず、パーキングブレーキが作動しなかった”埋もれても探せればよかったが、埋もれた
万博まともに出来たことってあるのか？
https://ja.wikipedia.org/wiki/Controller_Area_Network 一つの車体内の有線内の通信の話と思われる。システムとしてはブレーキするよう指示出したが、その指示が末端のブレーキのところに届いてないというような話。
protocol設定間違ってたってことか/250kbpsより500kbpsにしたほうがいいとかそういう話じゃないのはどう読んでもわかると思うんだが/ブコメに大量にいるけど他人を馬鹿にしたいがために自分の無知を晒すの面白いの？
というかバス側で一定時間内になにも受信できなかったら自動的にブレーキがかかって止まるくらいの機能は必要だと思うんだけどな。
基本的なフェイルセーフができてない気がするんだが、万博のためにスクラッチから実装したってわけじゃないんでしょ？
通信阻害されても「アクセル・ブレーキ・ステアリング」は手動操作可能になっとるからフェールセーフされとるよ。「パーキングブレーキ」が作動しなかった原因が通信阻害ね。/乗り物の話題ではアホになるブコメ達。
いやいやそこはデータ受信できてないときは一時停止とかが妥当な対処でしょ。受信速度落とすとその分反応が遅くなるってことでしょ
もう誰も万博の話しなくなったね
乗る側の感覚ではスイッチひとつ押したら従来のただのバスに切り替われよと思うけど、当然そうもいかないのだろう。とはいえ安全側に倒せない野生の鉄の塊が野放しになるのは怖い。
自律してないラジコンちゃうか
いすゞのergaと言うモデルらしいのだけど安全対策を見ると運転者に注意を促すがメインで、自動で止まるとかはなさそう。 https://www.isuzu.co.jp/product/bus/erga_ev/safety.html
そもそも万博でテスト段階のバスを走らせる意味があるのか疑問。「設定ミス」って単純ミスみたいに言ってるけど、ケガ人がいたら大事。
当該路線は日本の新興メーカーEVモーターズが納入している模様。 https://jidounten-lab.com/u_47769/ ソフトウェアは弱いのかね、、/プレス見てたらSB系列のBOLDLYという会社も噛んでそう。 https://www.softbank.jp/drive/
リセット後の通信ビットレートが間違っててCANのコンポーネント同士が通信できませんでしたということ？
ビームシールドでビームライフルを防いでたらヴェスバーでぶち抜かれたみたいな話？
？
自動運転バス、データ渋滞でブレーキ迷子にゃ？ボクなら華麗に避けるにゃ！🐾
基本はブレーキかけっぱなし、通信が成功したらブレーキを解除できる、じゃないの？フェイルセーフって知ってる？？？？
90年代にSNA（とその亜流）からTCP/IPへ移行したように、車載ネットワークの世界でも2020年前後からCANからIPへの移行が進んでると思ってたんだが…。高速通信が求められそうな自動運転もいまだにCANなのか
テスト不足？
この対応で大丈夫なのかわからんから怖いので乗らない
ブクマカの有識者たちの説明のおかげで理解すすんだ。有り難い
通信の処理落ちで停車中？に、自動運転によるパーキングブレーキを作動できず、動いてしまった？通信関連の処理がブレーキ処理に影響してしまうのはどうなのか。怪我なく改善点が見つかったのは良い事しかない
自動バス「ブレーキ指示、来ない・・・ずっと待ってるのにまだ来ない・・・オレどうしやらええんや。うぅ、もう限界、我慢できない・・・やるしかない、ぬぅぉ～～っ！」みたいな制御？
ハッキングされて特定の人物を轢く犯罪に使われそう。ミステリー作家の皆さんどうぞ
フェイルセーフになってなくて直前の命令が実行され続ける仕組みがそもそもヤバい
イット革命！デーエックス！
対策読んだけど、ネットつながらない時は自動停止した方がいいんでないか / ネットつながらない時は自動停止したあとパーキングブレーキもオンに、か
大阪メトロの発表そのままの報道だが、まったく理解できない。リセット通信だけがキャパオーバーな出力をしたの？特定ノード同士が個別にレートネゴする仕組みなの？
データ受信できないと暴走するの設計からおかしいんじゃ
こういう安全に関わるところはテストしまくるものだと思っていたが
ブコメが「◯◯するべきだろ、❌️❌️って知ってる？」とマウントだらけで大変よい
BYDなだけで乗る気にならないバス…当たり前の結果だろ。乗客が乗ってなくて良かった。
フェイルセーフの仕組みは実装されていた。しかし、自動運転バスが自ら意思を持ってフェイルセーフ機能を無効にした。というシンギュラリティが起きた可能性は……ないかー。
よくわからないのは、システムのエラーに気が付いて運転手がパーキングブレーキを操作したけど、エラーによって受け付けられないって話だから緊急事態の操作が受け付けられないに等しいので相当ヤバイと思うが？
信号なしでタイヤロックにするもんだと思ってた。
異常系テスト不足じゃん。実車両で正常系以外がテストし辛いのは分かるけども。
どっちかというとブレーキ信号を受信しないと壁にぶつかる設計に問題が有ると思うぞ
なんだか出来が悪いな
有識者のコメント助かる
まあ自動運転バスは普通のバスに比べて圧倒的に運行量も少ないし焦って再開する必要は全くないよね
大量にデータを送ってしまい、復号から漏れた命令に反応しなかったと。
事故時のニュース https://www3.nhk.or.jp/kansai-news/20250430/2000093633.html 今回指摘の現象で手動によるPブレーキが掛からず動いて事故と/無信号で自動停止は走行中(←も誤情報の可能性)だと危険
通信規格の問題？ それとも通信チップの問題？ 処理性能の問題？ ん～？
“いつまで経っても車両側から「リセット完了」という応答がないため、何度も送信を繰り返すことに。”よくある輻輳。リトライ処理を組む時は気をつけよう
エラーで埋まる通信もどうかと思うが。安全性のみの通信とか分けないと。250kがエラーで埋まったら止まるシステム？
よくこんな設計で。
自動運転難しそう(接続切れたら停止とかは生真面目に実装するとまともに走れなくなりそうで
なるほどてんかん発作か(違)／大阪メトロのサイトによると、エラーで手動運転に切り替えたがフットブレーキ信号が阻害され、フットブレーキが作動条件であるパーキングブレーキが効かなかったって流れ？
1次対処だけで、どうやったらミスを起こさないかについて人や業者を詰める以外の対策はないんですかね？さすが関西の鉄道は違いますなあ。設定自動化とか自動テストとか色々ありますけどねえ。
日本終了の知らせがこんな形で伝えられるとは
初期化処理がバグっていて、さらにそのフェールセーフの処理もおかしくて通信路（CANバスか?）を溢れさせブレーキが効かなく。で、直したのは通信路を溢れさせた直接の原因の後者ではなくトリガになった前者の方?
大阪メトロはバス停の時刻表示すら修正できないからITに関しては投げっぱなしでロクにテストもしてないんじゃないの？って偏見めいた感想。
漫画だと臨界事故とか起こすタイプのやつ
実機で動かしてないレベルのミスだな。チェックしてないのは何が要因なのか
設計の段階でフェイルセーフにしておくべき部分だよなあ。IT後進国はこれだから…
フェイルセーフがない仕組みって事かな。ある通信系が壊れたら止まらないって事かな。
この話題だと「バス」がどっちのことか分かりにくいw
安全マージンを取って400Gbpsでも受信できるようにしましょう
ってか車両の操作は車両内で完結しろよ これ自動運転じゃなくて、ただのリモート操作だろこれ
この程度のインシデントで済んで本当に良かったよね案件に見える
大阪メトロの6台てことはEVモーターズ・ジャパン製てことか
一度も通していないエラーケースがあったってことよね。ヤバくない？
万博と自動運転バス、見切り発車の上に走り出したら止められない点では同じ
まるで小生みたいなミスでわろた。小生もCANは嫌いです（逆恨み
ネットワークエラーの時はスタンドアローンで「今は安全な場所でじっとしてる」とか最低限の判断はできるくらいの脳みそを積んでおいたほうがいいんじゃないのか…ネットワークエラーなんていくらでも起こるんだから
こういう軽微なインシデントは蓄積していけばそれだけ自動運転バスは安全になっていくものだけど、なんで実地で経験値を積まねばならんのだ？サンドボックス環境作って安全に経験値積ませろよ
有識者コメありがたい。CAN知らんかったが同期通信250kbpsのところ500kbps設定なので1bit周期に対して2bit送ってたということか。仕様として優先度や通信重なった時の調停もありそうだけど通信速度間違ってたら機能せんか。
ブレーキが自律でできないの怖いな。命令が来ていないのと受信失敗をどう切り分けるか
別にCANの仕様どうこうじゃなくてなんでそうなんねんという話だし、誤りを直しただけじゃ再発防止になってないがという気持ち悪さ
コメントしてるみんなは詳しいなあ。万博のスタッフも詳しい人がいるはずなのにね
完全に実証実験の不足による不具合ね、異常系のテストも無しに実運用させようとしてたの？
専門家（学者）軽視は維新のオハコ。山師が跋扈する土壌にもなる。機械翻訳を丸写したような案内パンフレットの外国語とか、指摘されていた無用な水たまりの配置、面妖な埋め立て地に於けるレジオネラ属菌対策とか。
あまりにもデリケートすぎ。遠隔通信でそんなに速度安定してることってないような気がする。天候とか温度とか中間サーバーとかケーブルの材質で通信速度変わるよね。輻輳を前提としたプロトコルにしなよ
全然わかんなくて草。フェールセーフ機構がどういう順序で働く設計になってて、どこが機能不全になって事故に至ったかの方を教えてくれよｗ
バスオフしちゃいましたって話ね。バスだけに…。。
自動運転タクシーも実現してる中国でこの手のトラブル聞いたことないけどどうしてるんだろ？
逆になんで今までちゃんと動いてたんや? と思ったら "なお、リセット処理時以外の自動運転システムの通信速度は250kbpsである" と別記事にあった。例外処理のテスト漏れか
ギリギリに設定するとジッターで輻輳してなんか欠落するんじゃね
なるほど。エラー回復時だけか / 「エラー情報を検知した際は、送受信をリセットして初期化する」「この際の「設定ミス」」「車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていた」
テストしてなかったのがバレた。
レベル4以上をやってるということ？／運転手がブレーキかけたけど効かなかったみたいな話か。どっちにしろおっかない
万が一人に被害が出てたら日本の自動運転は終わってたな。世界中で普及しても許可されない未来が見える
情報が早くて逸り事故るかな
詳しくないからわからんけど、その設定変えるだけでいいんかと不安になってしまうな…実際は他にもやってるんだろうけど…
イレギュラーが起きたら「止まる」がディフォルトでは？
ちょ、ちょっと待って。これは不具合以前に根本的な設計ミスに感じるんですけど、本当に大丈夫なのでしょうか。
エンジニアが疑わしき時は兎にも角にも停止するって実装してないとも思えないけれどなぁ
大阪万博2025は命がけのイベント、バスの暴走にガス爆発、USJなんて目じゃない危うさ。イキってる不良を送り込む短期刑務所にすれば入場者数も伸ばせて維新も本望では?
フェイルセーフ的なのはなかったのかな
フレーム問題だ
この書き方だといまいちよくわからない……Xtechとかで詳細出るまでなんとも(フェイルセーフについてのコメントが複数あるけど、「何かあった時にパーキングブレーキかける方に倒れる」機構はそれはそれでヤバくね？感
世界よこれが日本の誇る自動運転技術だ（毒
フェイルセーフはどこにいった？
万博会場と駐車場を結ぶ自動運転バスのシステム設計の会社は、先進モビリティ株式会社。これは 東京大学生産技術研究所に発するものであるが、BOLDLY と関係する。詳しくは → http://openblog.seesaa.net/article/515900141.html
乗用車のパーキングブレーキも、アクチュエータで掛けるタイプが普及してきてるが大丈夫か？
空飛ぶクルマに続いて交通機関の未来に不安が…
通信速度1/2に落としたらブレーキが作動するまで2倍時間かかるんじゃないの。
推測すると、通信エラーの再送信でバスの帯域があふれて、同じバスで行ったブレーキECUとの通信が到達しなかったってことでしょ？設計上のツッコミが結構あるように思うけど大丈夫？
まあ納品するだけなら設計とテストは飛ばしても製品は完成するからな
中国では2023年から50両の自動運転バスが投入され累計210万キロ116万人が利用しているというのに…日本製は性能悪くて駄目ね。やはりBYDには勝てないな。https://www.jetro.go.jp/biznews/2025/05/273f2e0c7a6e7cc6.html
この記事だけじゃ全然わかんなかった。ブコメの別記事リンク感謝。
>>車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていたため
オンラインで自動運転とか通信障害の時に怖いシステムを使ってるんだな。ある程度バックアップ的にスタンドアロンでも運用できるとか保険かけた設計にしとけばいいのに。
通信エラーは設定ミスとテスト不足、多分開発遅れとかで本番までに時間取れてない系。エラー時にPブレーキ作動せずは制御SWの機能安全性がの問題、これも検討不足っぽい。万博開催に向けてのデスマーチが見える
エラーのまま進行するなんて設計あり得ない
記事には書かれていないが、「動き出した」のは軽い坂だったことが理由でバスの自走ではない。パーキングに入れる設定にすると別の事故の危険性があり、通常ブレーキにすると人力で動かせなくなる。対処が難しい。
デカい事故に繋がる前で良かった……かな……
やはり漢民族のほうが優れた民族なんだな。我々はダメだ
バス通信のことITの知識ある人は全員知ってるべき、という人は現代のITエンジニアに対して思うことが多そうだな
念の為、運転席に１人座らせてハンドル握らせてイザと言う時はブレーキ踏めばいいんじゃない？（名案）
フォアグラ
電車なら即ブレーキがフェイルセーフになるだろうが自動車である場合そうもいかんだろうしな
テストしようねー
パッチ当てやな。リセット完了待ちにウォッチドッグタイマー入っていないの？
こういうしょうもなく思えるミスほど、実地で数こなして初めて分かるってことはあると思う。
暴走とかヤバいといってる人たちはニュースを読まずに創造で語ってドヤ顔してるのがバレバレだけど、はてブ民はそれに⭐️付けるからフェイク情報ばかり出回る。リテラシーの無さを否定できんのよね
乗用車向けの CAN (500kbps) の設定にした ECU を大型バスの 250kbps のバスにつないでセルフ DoS してた...ってコト？ そうだとすると 500kbps で喋る ECU は誰とも通信できない気がするけども、気づかないもんなのかしら...?
テストや検品体制に疑問を持ってもいい気はする
大学の研究室とかで、院生が学部生にLANの設定を教えたりするほのぼのさを連想したが…自動運転は遊びじゃねーんだぞ💢💢💢💢！！！！
万博がテストみたいなものだったのでしょう。公道に向けて。
ADが送信ACKエラーを検出し再送信する。送信ACKエラーではバスオフしないので延々と送信を繰返す。ADはビット長が他ノードの1/2でIFSが一番短いので、他ノードは永久に送信ノードになることができない ってこと?
異常系のテスト漏れか。
https://travelandtourism.zohodesk.in/portal/en/kb/articles/51-delta-telefono-pe-c%C3%B3mo-llamar-a-delta-airlines-per%C3%BA
"特定のバスにのみ発生" "弊社がこれまで出荷いたしました自動運転システムを搭載した車両、 その他の実証実験に使用してきた車両については(略)発生しないことを確認済み" https://www.as-mobi.com/news/?p=1#1749691356-978103
自動運転と言うよりは遠隔操作に近いのでは
これルートがわかったら、DDoS攻撃で簡単に暴走させられるって事なの？
車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていたため←映画の『スピード』じゃないんだから…周波数帯とか通信規格とかの話だよね？
手動操作に切り替えたにも関わらず、その手動操作を阻害するって運転手を一応乗せる意味が…。エアバス機かなｗ サイバーテロ対策としても自動を切ったら完全にマニュアル制御になる仕様が必要だと思うのだが。
万博・自動運転バス事故『原因＝車両が受信できない速度（500kbps）でデータ送信していた』大量のエラーデータで必要なブレーキ情報伝わらず…大阪メトロ | MBSニュース
“対策として通信速度設定を500kbpsから、250kbpsに書き換えた” なんか嫌な予感がする対処法だな？
回線細いなという点を突っ込めばいいのか、設定雑だなという点を突っ込めばいいのか
「対策として通信速度設定を500kbpsから、250kbpsに書き換えたということです」←応急処置だよな？そうだよな？
目を疑う気持ちで取りあえずブクマしたけどやっぱりこれ凄くまずい気がするよね…。更なる識者の意見待ち。
いろいろと謎が多すぎる。「通信が阻害」されたことで、車からパーキングブレーキが作動させられなくなる？／ネットワークには詳しくないけど、通信速度の設定、そんな、Tera Termでシリアル通信やるみたいな話なの？
「対策として通信速度設定を500kbpsから、250kbpsに書き換えたということです。」応急処置としては良いだろうけど安全に関わる部分なんだから速度が違っても安全が保たれるようにするべきなのでは
回線は太くしとけというのもあるが、フェールセーフ設計であるべきなのではと
いまの車は車両側にも基本的に自動ブレーキがついてると思うけどそちらは無効化されていたんだろうか？
え？ 必要な情報を車両側がちゃんと受けられるように車両側の通信設備を増強する方がよくね？ あと、想定外のことが起きたら、止まるように設計するのが基本だと思うんだが……。
無線ではなく車内で閉じたCANの話か? 送信し続けて輻輳しブレーキ命令が届かなかったって? 重大インシデントじゃん。初期化パラメータ直しただけで運行再開OKしていいレベルじゃない。絶対に輻輳しない手当てが必要だろ
早口すぎて聞き取れないみたいな感じなのかな
いま開発担当者の気持ちになってるんですけどね、ありがちな風景としては、無理筋な突貫開発と思いつつも不可能だと言える明確な理由は言えず走った結果⋯みたいな流れ。よくあることの想像ですけどね。
通信遮断されたら車側の自律自動停止処理が入っていないことに驚愕。あくまで管理側からの操作しなければならない設計は誰が許可したのかな？
動作チェックしてないってこと？ なにか昔のジョークでのマイクロソフトが車を作ったらみたいになってきた。
要領を得ない説明なので記者レベルに理解させるためにだいぶ情報が落ちてそう
“通信の設定ミスというのは、車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていたためでした。 対策として通信速度設定を500kbpsから、250kbpsに書き換えた”
自動運転はこの事故の前に別の不具合で動作停止中、手動運転に切替て自動パーキングブレーキが動作しなかった事例。エラーの錯綜でフットブレーキの信号が受信されなかったとのことだがRTOSじゃないのか...
詳しくないのですが、フェールセーフになってないように思えるのですが、理解不足でしょうか。
車の制御ってフェイルセーフが基本だと思ったけど、エラー時は端に寄せてパーキングブレーキかけるとかしてないんだ。鉄道系とか参考にしてないんか？
知ったかコメントする前に調べよう。既コメで既に指摘されてるが、これは恐らくCANで、250kbpsが基本規格のバスに500kbps流したら輻輳になるのITの知識あれば当たり前だって分かる、分からない方がむしろITとしては恥では？
エラーでわからんくなったらデフォで止まるってシステムじゃないんか
それ対策じゃねーから
CANプロトコルはすごいよくできてんだけどCANバス自体は中央制御する仕組みがないので一人でもアホの子がいるとこういう事態を招く。
こっちの方が少し詳しい。複数のシチュエーションで異なる通信速度を設定できるように見える https://subway.osakametro.co.jp/news/news_release/20250611_park_and_ride_bus.php
的外れなコメントが多すぎると感じるが、しかし、こんなプロジェクトで異常系を評価していないという事実と、基本制御の通信バスに割り込ませる設計なんだ(まあ多重化とかないか)という感想
この記事では良くわからんのでこっちを見た方が良い。 https://x.gd/W8T9M 自動運転システムが車両側システムにDOS攻撃(RSTフラッド？)した感じだけど、脆弱性として狙われそうな気もする
根本的にあかん。／対策するなら「問題発生時は自律で安全停止する」というものだし、普通は最初からそうなっていると思うが。自律停止できないレベルまでシステムを切り刻んでいるのならその設計はやめろ。
CANは調歩同期式なので、取り決めた通信速度以外ではそもそも受信できない(ビットを正しく解釈できない)。なので通信速度の修正は応急処置ではなく根本対策。ていうかテストしてないのかよ
『手動運転』という言葉の響きから機械制御な印象を受けるけど、自己報告書を読む限りはそもそもが電子制御だから手動操作も一つの通信でしかない、通信エラーで手動操作も受け付けないてのは直感に反するかも
ボーレートの設定ミスはともかく、異常時にブレーキの信号を阻害するのは怖い。車のパーキングブレーキも強制ONができるけどそういうのはなかったのかな。全然関係ないけど250kbpsってDMX512を彷彿とさせる。
デバッグと調整は実証現場でやるとか笑えんのやで。ホンマ議員や公務員の責任所在の明確化と厳罰化をせんと「税金おいしーれす」なゲスに食われるだけやからな。先ずはとっととスパイ防止法を立法せえ。
この記事だけ見れば、具体的な数値に言及して対策も記載されているだけに、そもそもの設計思想（フェイルセーフ）についてツッコミがたくさん来そうだが、そんなこと想定して記事を書いてるわけも当然ないよね。
よくわからんが高い通信速度に車両側が対応してなかったってことなのかな
鉄道事業者としておかしいと思わないんだろうか、鉄道だったら即非常ブレーキでしょこんなの
お粗末すぎる……万博(笑)
まあちょっと危なっかしい話だなとは思うけど、自動運転車の事故が過剰に報じられると導入が遠くなるので冷静に対応、静観しつつ、どんどん技術と制度を前に進めてほしい
無理矢理間に合わせたみたいな付け焼き刃感がすごい(ノ∀`)
設定ミスはまあしゃーないが（人的被害がないのは良かった）、作ったメーカーはフェイルセーフの概念がないのか？ / 絶対輻輳しない仕組み以前に輻輳したとしても安全側に倒す対策が必要。
対策が再発防止できてないような
CANバスのそのぐらいの事象でフォールトトレラントに出来ないシステムなのに市場に出してるんだ／自動運転システムは先進モビリティ（茨城県つくば市）が開発とのこと
とりあえずF-2戦闘機のFBW配線が逆に接続できて挙動が逆になるような設定ミス的ななつ?
外部の通信に運転を依存してるのおかしいだろ。データ量にもよると思う。操作側も連打してんじゃねーよ確認しろよバーカ。
“送信された大量のエラーデータで通信が阻害された結果、車側で、パーキングブレーキを作業するよう出した情報も阻害されて伝わらず、パーキングブレーキが作動しなかった”埋もれても探せればよかったが、埋もれた
万博まともに出来たことってあるのか？
https://ja.wikipedia.org/wiki/Controller_Area_Network 一つの車体内の有線内の通信の話と思われる。システムとしてはブレーキするよう指示出したが、その指示が末端のブレーキのところに届いてないというような話。
protocol設定間違ってたってことか/250kbpsより500kbpsにしたほうがいいとかそういう話じゃないのはどう読んでもわかると思うんだが/ブコメに大量にいるけど他人を馬鹿にしたいがために自分の無知を晒すの面白いの？
というかバス側で一定時間内になにも受信できなかったら自動的にブレーキがかかって止まるくらいの機能は必要だと思うんだけどな。
基本的なフェイルセーフができてない気がするんだが、万博のためにスクラッチから実装したってわけじゃないんでしょ？
通信阻害されても「アクセル・ブレーキ・ステアリング」は手動操作可能になっとるからフェールセーフされとるよ。「パーキングブレーキ」が作動しなかった原因が通信阻害ね。/乗り物の話題ではアホになるブコメ達。
いやいやそこはデータ受信できてないときは一時停止とかが妥当な対処でしょ。受信速度落とすとその分反応が遅くなるってことでしょ
もう誰も万博の話しなくなったね
乗る側の感覚ではスイッチひとつ押したら従来のただのバスに切り替われよと思うけど、当然そうもいかないのだろう。とはいえ安全側に倒せない野生の鉄の塊が野放しになるのは怖い。
自律してないラジコンちゃうか
いすゞのergaと言うモデルらしいのだけど安全対策を見ると運転者に注意を促すがメインで、自動で止まるとかはなさそう。 https://www.isuzu.co.jp/product/bus/erga_ev/safety.html
そもそも万博でテスト段階のバスを走らせる意味があるのか疑問。「設定ミス」って単純ミスみたいに言ってるけど、ケガ人がいたら大事。
当該路線は日本の新興メーカーEVモーターズが納入している模様。 https://jidounten-lab.com/u_47769/ ソフトウェアは弱いのかね、、/プレス見てたらSB系列のBOLDLYという会社も噛んでそう。 https://www.softbank.jp/drive/
リセット後の通信ビットレートが間違っててCANのコンポーネント同士が通信できませんでしたということ？
ビームシールドでビームライフルを防いでたらヴェスバーでぶち抜かれたみたいな話？
？
自動運転バス、データ渋滞でブレーキ迷子にゃ？ボクなら華麗に避けるにゃ！🐾
基本はブレーキかけっぱなし、通信が成功したらブレーキを解除できる、じゃないの？フェイルセーフって知ってる？？？？
90年代にSNA（とその亜流）からTCP/IPへ移行したように、車載ネットワークの世界でも2020年前後からCANからIPへの移行が進んでると思ってたんだが…。高速通信が求められそうな自動運転もいまだにCANなのか
テスト不足？
この対応で大丈夫なのかわからんから怖いので乗らない
ブクマカの有識者たちの説明のおかげで理解すすんだ。有り難い
通信の処理落ちで停車中？に、自動運転によるパーキングブレーキを作動できず、動いてしまった？通信関連の処理がブレーキ処理に影響してしまうのはどうなのか。怪我なく改善点が見つかったのは良い事しかない
自動バス「ブレーキ指示、来ない・・・ずっと待ってるのにまだ来ない・・・オレどうしやらええんや。うぅ、もう限界、我慢できない・・・やるしかない、ぬぅぉ～～っ！」みたいな制御？
ハッキングされて特定の人物を轢く犯罪に使われそう。ミステリー作家の皆さんどうぞ
フェイルセーフになってなくて直前の命令が実行され続ける仕組みがそもそもヤバい
イット革命！デーエックス！
対策読んだけど、ネットつながらない時は自動停止した方がいいんでないか / ネットつながらない時は自動停止したあとパーキングブレーキもオンに、か
大阪メトロの発表そのままの報道だが、まったく理解できない。リセット通信だけがキャパオーバーな出力をしたの？特定ノード同士が個別にレートネゴする仕組みなの？
データ受信できないと暴走するの設計からおかしいんじゃ
こういう安全に関わるところはテストしまくるものだと思っていたが
ブコメが「◯◯するべきだろ、❌️❌️って知ってる？」とマウントだらけで大変よい
BYDなだけで乗る気にならないバス…当たり前の結果だろ。乗客が乗ってなくて良かった。
フェイルセーフの仕組みは実装されていた。しかし、自動運転バスが自ら意思を持ってフェイルセーフ機能を無効にした。というシンギュラリティが起きた可能性は……ないかー。
よくわからないのは、システムのエラーに気が付いて運転手がパーキングブレーキを操作したけど、エラーによって受け付けられないって話だから緊急事態の操作が受け付けられないに等しいので相当ヤバイと思うが？
信号なしでタイヤロックにするもんだと思ってた。
異常系テスト不足じゃん。実車両で正常系以外がテストし辛いのは分かるけども。
どっちかというとブレーキ信号を受信しないと壁にぶつかる設計に問題が有ると思うぞ
なんだか出来が悪いな
有識者のコメント助かる
まあ自動運転バスは普通のバスに比べて圧倒的に運行量も少ないし焦って再開する必要は全くないよね
大量にデータを送ってしまい、復号から漏れた命令に反応しなかったと。
事故時のニュース https://www3.nhk.or.jp/kansai-news/20250430/2000093633.html 今回指摘の現象で手動によるPブレーキが掛からず動いて事故と/無信号で自動停止は走行中(←も誤情報の可能性)だと危険
通信規格の問題？ それとも通信チップの問題？ 処理性能の問題？ ん～？
“いつまで経っても車両側から「リセット完了」という応答がないため、何度も送信を繰り返すことに。”よくある輻輳。リトライ処理を組む時は気をつけよう
エラーで埋まる通信もどうかと思うが。安全性のみの通信とか分けないと。250kがエラーで埋まったら止まるシステム？
よくこんな設計で。
自動運転難しそう(接続切れたら停止とかは生真面目に実装するとまともに走れなくなりそうで
なるほどてんかん発作か(違)／大阪メトロのサイトによると、エラーで手動運転に切り替えたがフットブレーキ信号が阻害され、フットブレーキが作動条件であるパーキングブレーキが効かなかったって流れ？
1次対処だけで、どうやったらミスを起こさないかについて人や業者を詰める以外の対策はないんですかね？さすが関西の鉄道は違いますなあ。設定自動化とか自動テストとか色々ありますけどねえ。
日本終了の知らせがこんな形で伝えられるとは
初期化処理がバグっていて、さらにそのフェールセーフの処理もおかしくて通信路（CANバスか?）を溢れさせブレーキが効かなく。で、直したのは通信路を溢れさせた直接の原因の後者ではなくトリガになった前者の方?
大阪メトロはバス停の時刻表示すら修正できないからITに関しては投げっぱなしでロクにテストもしてないんじゃないの？って偏見めいた感想。
漫画だと臨界事故とか起こすタイプのやつ
実機で動かしてないレベルのミスだな。チェックしてないのは何が要因なのか
設計の段階でフェイルセーフにしておくべき部分だよなあ。IT後進国はこれだから…
フェイルセーフがない仕組みって事かな。ある通信系が壊れたら止まらないって事かな。
この話題だと「バス」がどっちのことか分かりにくいw
安全マージンを取って400Gbpsでも受信できるようにしましょう
ってか車両の操作は車両内で完結しろよ これ自動運転じゃなくて、ただのリモート操作だろこれ
この程度のインシデントで済んで本当に良かったよね案件に見える
大阪メトロの6台てことはEVモーターズ・ジャパン製てことか
一度も通していないエラーケースがあったってことよね。ヤバくない？
万博と自動運転バス、見切り発車の上に走り出したら止められない点では同じ
まるで小生みたいなミスでわろた。小生もCANは嫌いです（逆恨み
ネットワークエラーの時はスタンドアローンで「今は安全な場所でじっとしてる」とか最低限の判断はできるくらいの脳みそを積んでおいたほうがいいんじゃないのか…ネットワークエラーなんていくらでも起こるんだから
こういう軽微なインシデントは蓄積していけばそれだけ自動運転バスは安全になっていくものだけど、なんで実地で経験値を積まねばならんのだ？サンドボックス環境作って安全に経験値積ませろよ
有識者コメありがたい。CAN知らんかったが同期通信250kbpsのところ500kbps設定なので1bit周期に対して2bit送ってたということか。仕様として優先度や通信重なった時の調停もありそうだけど通信速度間違ってたら機能せんか。
ブレーキが自律でできないの怖いな。命令が来ていないのと受信失敗をどう切り分けるか
別にCANの仕様どうこうじゃなくてなんでそうなんねんという話だし、誤りを直しただけじゃ再発防止になってないがという気持ち悪さ
コメントしてるみんなは詳しいなあ。万博のスタッフも詳しい人がいるはずなのにね
完全に実証実験の不足による不具合ね、異常系のテストも無しに実運用させようとしてたの？
専門家（学者）軽視は維新のオハコ。山師が跋扈する土壌にもなる。機械翻訳を丸写したような案内パンフレットの外国語とか、指摘されていた無用な水たまりの配置、面妖な埋め立て地に於けるレジオネラ属菌対策とか。
あまりにもデリケートすぎ。遠隔通信でそんなに速度安定してることってないような気がする。天候とか温度とか中間サーバーとかケーブルの材質で通信速度変わるよね。輻輳を前提としたプロトコルにしなよ
全然わかんなくて草。フェールセーフ機構がどういう順序で働く設計になってて、どこが機能不全になって事故に至ったかの方を教えてくれよｗ
バスオフしちゃいましたって話ね。バスだけに…。。
自動運転タクシーも実現してる中国でこの手のトラブル聞いたことないけどどうしてるんだろ？
逆になんで今までちゃんと動いてたんや? と思ったら "なお、リセット処理時以外の自動運転システムの通信速度は250kbpsである" と別記事にあった。例外処理のテスト漏れか
ギリギリに設定するとジッターで輻輳してなんか欠落するんじゃね
なるほど。エラー回復時だけか / 「エラー情報を検知した際は、送受信をリセットして初期化する」「この際の「設定ミス」」「車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていた」
テストしてなかったのがバレた。
レベル4以上をやってるということ？／運転手がブレーキかけたけど効かなかったみたいな話か。どっちにしろおっかない
万が一人に被害が出てたら日本の自動運転は終わってたな。世界中で普及しても許可されない未来が見える
情報が早くて逸り事故るかな
詳しくないからわからんけど、その設定変えるだけでいいんかと不安になってしまうな…実際は他にもやってるんだろうけど…
イレギュラーが起きたら「止まる」がディフォルトでは？
ちょ、ちょっと待って。これは不具合以前に根本的な設計ミスに感じるんですけど、本当に大丈夫なのでしょうか。
エンジニアが疑わしき時は兎にも角にも停止するって実装してないとも思えないけれどなぁ
大阪万博2025は命がけのイベント、バスの暴走にガス爆発、USJなんて目じゃない危うさ。イキってる不良を送り込む短期刑務所にすれば入場者数も伸ばせて維新も本望では?
フェイルセーフ的なのはなかったのかな
フレーム問題だ
この書き方だといまいちよくわからない……Xtechとかで詳細出るまでなんとも(フェイルセーフについてのコメントが複数あるけど、「何かあった時にパーキングブレーキかける方に倒れる」機構はそれはそれでヤバくね？感
世界よこれが日本の誇る自動運転技術だ（毒
フェイルセーフはどこにいった？
万博会場と駐車場を結ぶ自動運転バスのシステム設計の会社は、先進モビリティ株式会社。これは 東京大学生産技術研究所に発するものであるが、BOLDLY と関係する。詳しくは → http://openblog.seesaa.net/article/515900141.html
乗用車のパーキングブレーキも、アクチュエータで掛けるタイプが普及してきてるが大丈夫か？
空飛ぶクルマに続いて交通機関の未来に不安が…
通信速度1/2に落としたらブレーキが作動するまで2倍時間かかるんじゃないの。
推測すると、通信エラーの再送信でバスの帯域があふれて、同じバスで行ったブレーキECUとの通信が到達しなかったってことでしょ？設計上のツッコミが結構あるように思うけど大丈夫？
まあ納品するだけなら設計とテストは飛ばしても製品は完成するからな
中国では2023年から50両の自動運転バスが投入され累計210万キロ116万人が利用しているというのに…日本製は性能悪くて駄目ね。やはりBYDには勝てないな。https://www.jetro.go.jp/biznews/2025/05/273f2e0c7a6e7cc6.html
この記事だけじゃ全然わかんなかった。ブコメの別記事リンク感謝。
>>車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていたため
オンラインで自動運転とか通信障害の時に怖いシステムを使ってるんだな。ある程度バックアップ的にスタンドアロンでも運用できるとか保険かけた設計にしとけばいいのに。
通信エラーは設定ミスとテスト不足、多分開発遅れとかで本番までに時間取れてない系。エラー時にPブレーキ作動せずは制御SWの機能安全性がの問題、これも検討不足っぽい。万博開催に向けてのデスマーチが見える
エラーのまま進行するなんて設計あり得ない
記事には書かれていないが、「動き出した」のは軽い坂だったことが理由でバスの自走ではない。パーキングに入れる設定にすると別の事故の危険性があり、通常ブレーキにすると人力で動かせなくなる。対処が難しい。
デカい事故に繋がる前で良かった……かな……
やはり漢民族のほうが優れた民族なんだな。我々はダメだ
バス通信のことITの知識ある人は全員知ってるべき、という人は現代のITエンジニアに対して思うことが多そうだな
念の為、運転席に１人座らせてハンドル握らせてイザと言う時はブレーキ踏めばいいんじゃない？（名案）
フォアグラ
電車なら即ブレーキがフェイルセーフになるだろうが自動車である場合そうもいかんだろうしな
テストしようねー
パッチ当てやな。リセット完了待ちにウォッチドッグタイマー入っていないの？
こういうしょうもなく思えるミスほど、実地で数こなして初めて分かるってことはあると思う。
暴走とかヤバいといってる人たちはニュースを読まずに創造で語ってドヤ顔してるのがバレバレだけど、はてブ民はそれに⭐️付けるからフェイク情報ばかり出回る。リテラシーの無さを否定できんのよね
乗用車向けの CAN (500kbps) の設定にした ECU を大型バスの 250kbps のバスにつないでセルフ DoS してた...ってコト？ そうだとすると 500kbps で喋る ECU は誰とも通信できない気がするけども、気づかないもんなのかしら...?
テストや検品体制に疑問を持ってもいい気はする
大学の研究室とかで、院生が学部生にLANの設定を教えたりするほのぼのさを連想したが…自動運転は遊びじゃねーんだぞ💢💢💢💢！！！！
万博がテストみたいなものだったのでしょう。公道に向けて。
ADが送信ACKエラーを検出し再送信する。送信ACKエラーではバスオフしないので延々と送信を繰返す。ADはビット長が他ノードの1/2でIFSが一番短いので、他ノードは永久に送信ノードになることができない ってこと?
異常系のテスト漏れか。
https://travelandtourism.zohodesk.in/portal/en/kb/articles/51-delta-telefono-pe-c%C3%B3mo-llamar-a-delta-airlines-per%C3%BA
"特定のバスにのみ発生" "弊社がこれまで出荷いたしました自動運転システムを搭載した車両、 その他の実証実験に使用してきた車両については(略)発生しないことを確認済み" https://www.as-mobi.com/news/?p=1#1749691356-978103
自動運転と言うよりは遠隔操作に近いのでは
これルートがわかったら、DDoS攻撃で簡単に暴走させられるって事なの？
車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていたため←映画の『スピード』じゃないんだから…周波数帯とか通信規格とかの話だよね？
手動操作に切り替えたにも関わらず、その手動操作を阻害するって運転手を一応乗せる意味が…。エアバス機かなｗ サイバーテロ対策としても自動を切ったら完全にマニュアル制御になる仕様が必要だと思うのだが。