www.mbs.jp
subway.osakametro.co.jp
毎日新聞のこのまとめ方は、正直難がある。が、大阪メトロの報告書も難がある。
大阪メトロの報告によりますと、自動運転システムは、ネットワークシステムからエラー情報を検知した際は、送受信をリセットして初期化するようプログラムされていますが、この際の「設定ミス」があったことから、車両側でデータを受信できない状態となっていました。
いっぽうシステム側は、いつまで経っても車両側から「リセット完了」という応答がないため、何度も送信を繰り返すことに。
送信された大量のエラーデータで通信が阻害された結果、車側で、パーキングブレーキを作業するよう出した情報も阻害されて伝わらず、パーキングブレーキが作動しなかった、結果車が動いて壁にぶつかった、ということです。
さて、その通信の設定ミスというのは、車両側が認識できるデータ速度（250kbps）を超える速度（500kbps）で送っていたためでした。
対策として通信速度設定を500kbpsから、250kbpsに書き換えたということです。
万博・自動運転バス事故『原因＝車両が受信できない速度（500kbps）でデータ送信していた』大量のエラーデータで必要なブレーキ情報伝わらず…大阪メトロ | MBSニュース
当社が、当該車両に搭載した自動運転システムは、車両のネットワークシステムからのエラー情報を検知した場合、車両に対し送受信をリセット処理（初期化）するようプログラムされていますが、このリセット処理データを送信する通信速度に設定誤りがあり、車両側ではリセット処理データを正しく受信できませんでした。自動運転システムは、車両側からのリセット処理完了の応答がないためリセット処理データの送信を繰り返され、大量のエラーデータが発生したため、車両内のネットワーク通信が阻害された結果、パーキングブレーキが作動するための車両情報が伝わらず、パーキングブレーキが作動しなかったものです。
舞洲万博P&R駐車場の待機場における自動運転バス車両のコンクリート擁壁接触事故の原因と今後の対応について｜Osaka Metro
おそらく、下のブコメが状況を把握したものと思われる。そういや、車の電子制御って、そもそもTCP/IPとかではやってないんよな。
CANかどうかは確定はしてないが、類似の仕様ではあろうかと。
万博・自動運転バス事故『原因＝車両が受信できない速度（500kbps）でデータ送信していた』大量のエラーデータで必要なブレーキ情報伝わらず…大阪メトロ | MBSニュースb.hatena.ne.jp無線ではなく車内で閉じたCANの話か? 送信し続けて輻輳しブレーキ命令が届かなかったって? 重大インシデントじゃん。初期化パラメータ直しただけで運行再開OKしていいレベルじゃない。絶対に輻輳しない手当てが必要だろ
2025/06/12 08:45
万博・自動運転バス事故『原因＝車両が受信できない速度（500kbps）でデータ送信していた』大量のエラーデータで必要なブレーキ情報伝わらず…大阪メトロ | MBSニュースb.hatena.ne.jp知ったかコメントする前に調べよう。既コメで既に指摘されてるが、これは恐らくCANで、250kbpsが基本規格のバスに500kbps流したら輻輳になるのITの知識あれば当たり前だって分かる、分からない方がむしろITとしては恥では？
2025/06/12 09:23
万博・自動運転バス事故『原因＝車両が受信できない速度（500kbps）でデータ送信していた』大量のエラーデータで必要なブレーキ情報伝わらず…大阪メトロ | MBSニュースb.hatena.ne.jpCANプロトコルはすごいよくできてんだけどCANバス自体は中央制御する仕組みがないので一人でもアホの子がいるとこういう自体を招く。
2025/06/12 09:39
万博・自動運転バス事故『原因＝車両が受信できない速度（500kbps）でデータ送信していた』大量のエラーデータで必要なブレーキ情報伝わらず…大阪メトロ | MBSニュースb.hatena.ne.jpCANは調歩同期式なので、取り決めた通信速度以外ではそもそも受信できない(ビットを正しく解釈できない)。なので通信速度の修正は応急処置ではなく根本対策。ていうかテストしてないのかよ
2025/06/12 09:51
CANの説明以下
Controller Area Network - Wikipedia
ビークルバス - Wikipedia
技術コラム Vol.20 いまさら聞けない通信の話 ～CAN編～ | 株式会社アルファプロジェクト
これ、推測なんだが、リセット処理の通信が設定異常だったというのは、このリセット処理あんまりシステム的に考慮されていない虞がある。正直、他の異常処理でも入り込んでる可能性はありそう。
運転手がフットブレーキを踏んでいただろうにも関わらず、ログが取れない（=検知出来ていない）というような事態が起こる原因と調査、必要なら修理がいるだろう。今の改修で手動運転出来れば運航は出来るだろうが、そもそも車体とシステムに異常があるものを無理に運行はさせられないよなあ。
あと、実地テストすると言われているが、その前に、テストの抜け漏れがある為に、自動運転システムのテスト項目の洗い出しされている事は必要かと。
今後だが、パーキングブレーキは経路分けた方がよくない？
確かに流用度考えると一緒にするのありなんだが、自動運転システムを上にかぶせるんだったら違う線にしないと形式認可の範疇外になりそう。
同じ経路に流すのは避けられないところはあるのだが、ゆうて結構自動車の運転上きわめて大事なセーフティなので、自動運転システムに安全性壊されるのはちとなあ。。。。。。
最近のIT屋さんは、あんまり低レベルのネットワークの話は知らんとは思われる。
基本情報処理でハブ型とかスター型とかやった記憶はあるが、みんなリピータハブとか知らんやろもう。ネットワーク屋さんはかろうじて知ってるかもだけど、最近、「速度遅いんやけど」「多分100BASE-T相当の速度では足らんで」って話したら、ピンと来てなかったので
案外そうでもないかもしれん。
ルーターが今Linuxかなってのを積んでるのもなあ。昔はPC一台まるっと使ってたりしたんやが。
あと、車載のものは、かなり耐久性とかを要求されるってのは考えておいた方がいい。環境が氷点下超えたり灼熱だったり、落雷もしたりするわけでシールドもいるからなあ。昔オッサン液晶色々触ってたんやけど、液晶の動く温度で氷点下も固まらんとかは普通はないのよ。有機ELはだいぶ温度変化には強いとかある。意外とクソみたいな値段するなあってのも、実は理由がしっかりあったりするんよね。
安易に考えず、「どうしてそんな事になるんやろうか」は調べて知識として入れておいた方がええと思う。
