つまりろくにテストされてないまま運用始めちゃったのね。そして修正した部分関連のテストしかせずに運行再開しちゃうのね。まあ調査修正に半年とか許されない状況なのは理解できるけど、人命軽視しすぎ。
“②自動運転システム側がリセット処理データを送信する際に、車両側が認識できるデータ通信速度（250kbps）を超える通信速度（500kbps）で送信していたこと”倍盛されたらオーバーフローになる罠
この説明内容(リセット処理する通信速度の閾値変更)では通信阻害によるパーキングブレーキの不具合問題が解消されるのかちょっと不安。その点は今後のテスト走行で十分検証して欲しいと思う
まぁ技術にバグはつきものだから頑張れ
「車両側が認識できるデータ通信速度（250kbps）を超える通信速度（500kbps）で送信していたこと」／ビットレート設定間違えたらそりゃ流しても受信できませんわね…
「ネットワーク通信が阻害された場合においても、アクセル・ブレーキ・ステアリングが問題なく操作できることを確認済です」さすがにそうだろうけど、パーキングブレーキも操作できないとダメなのでは
リセット処理データだけ通信速度の設定が別になってたということかな。
有人かつ手動運転で自動運転時ではないんやから落ち着いてブレーキ踏んでパーキングブレーキの操作を試したらよかったね。慌てるだろうし事故ったのは仕方がない、自動運転が危ないとなるのがどうかしてる。
“他の同システム搭載車両についても同様の対策を講じました”、同じ設定ミスがされていた、と。
今回の原因（設定ミス）を直したとしても他の何らかの理由で通信が阻害される可能性（異常系）があるから、通信を当てにしない手動操作でオーバーライドする伝達経路が必要なのでは？と思ってしまう。
この調子だと外乱で容易に暴走しそうだね
いい実証実験できてるね。結果として物損だけど運転手が気付いてアクション取れているのも良い。
油圧。油圧がすべてを解決する(オーバーライドできる予備系統)。
物理的に操作しようにも、フットブレーキ操作が反映されるのにソフトウェア処理が必要だったと
こんなお粗末な事故を防げない26262は撤回していただいて、61508準拠でよろしく、という感想。
メッセージレートの誤設定でCANが輻輳。運悪くパーキングの作動条件がCAN依存だったので、運転手のパーキング操作がキャンセルされたと。これ車両にも問題あるだろ。CAN通信不良でパーキングキャンセルが普通に起きる。
素人目には自動運転時でもパーキングブレーキにはフットブレーキ操作が必要なので処理系が自動運転の方にくっついていて手動運転でもこれを利用する構成にしたように読める。他の手動装置の処理系は独立してたのでは
“なお、リセット処理時以外の自動運転システムの通信速度は250kbpsである” なんで今まで動いてたんやと思ったら
成長
停止方向への手動操作がオーバーライドされない自動運転システムは不味いな
なんのことか分からんが色々やって技術を進化させておくれ
この対応で大丈夫？他の何かで輻輳したら再発しそうだけど
通信で受信したリセット処理の破損データが、パーキング制御系を阻害したとすれば、車載ネットワークの構成がおかしい。そうでなく別のネットワークに分けられていたのなら、ブリッジへの攻撃として機能した？
まぁ、人命を犠牲にせず、EVMJ×先進モビリティの自動運転車は割とかなり不味かったとわかったのは収穫かもね…。大学発ベンチャーへの偏見が強まりそうだ私
CANなの？
バグでCANが輻輳→フットブレーキで停車状態になったことをシステムが検知できず→停車したのにパーキングブレーキが動作せず、か。
舞洲万博P&R駐車場の待機場における自動運転バス車両のコンクリート擁壁接触事故の原因と今後の対応について｜Osaka Metro
つまりろくにテストされてないまま運用始めちゃったのね。そして修正した部分関連のテストしかせずに運行再開しちゃうのね。まあ調査修正に半年とか許されない状況なのは理解できるけど、人命軽視しすぎ。
“②自動運転システム側がリセット処理データを送信する際に、車両側が認識できるデータ通信速度（250kbps）を超える通信速度（500kbps）で送信していたこと”倍盛されたらオーバーフローになる罠
この説明内容(リセット処理する通信速度の閾値変更)では通信阻害によるパーキングブレーキの不具合問題が解消されるのかちょっと不安。その点は今後のテスト走行で十分検証して欲しいと思う
まぁ技術にバグはつきものだから頑張れ
「車両側が認識できるデータ通信速度（250kbps）を超える通信速度（500kbps）で送信していたこと」／ビットレート設定間違えたらそりゃ流しても受信できませんわね…
「ネットワーク通信が阻害された場合においても、アクセル・ブレーキ・ステアリングが問題なく操作できることを確認済です」さすがにそうだろうけど、パーキングブレーキも操作できないとダメなのでは
リセット処理データだけ通信速度の設定が別になってたということかな。
有人かつ手動運転で自動運転時ではないんやから落ち着いてブレーキ踏んでパーキングブレーキの操作を試したらよかったね。慌てるだろうし事故ったのは仕方がない、自動運転が危ないとなるのがどうかしてる。
“他の同システム搭載車両についても同様の対策を講じました”、同じ設定ミスがされていた、と。
今回の原因（設定ミス）を直したとしても他の何らかの理由で通信が阻害される可能性（異常系）があるから、通信を当てにしない手動操作でオーバーライドする伝達経路が必要なのでは？と思ってしまう。
この調子だと外乱で容易に暴走しそうだね
いい実証実験できてるね。結果として物損だけど運転手が気付いてアクション取れているのも良い。
油圧。油圧がすべてを解決する(オーバーライドできる予備系統)。
物理的に操作しようにも、フットブレーキ操作が反映されるのにソフトウェア処理が必要だったと
こんなお粗末な事故を防げない26262は撤回していただいて、61508準拠でよろしく、という感想。
メッセージレートの誤設定でCANが輻輳。運悪くパーキングの作動条件がCAN依存だったので、運転手のパーキング操作がキャンセルされたと。これ車両にも問題あるだろ。CAN通信不良でパーキングキャンセルが普通に起きる。
素人目には自動運転時でもパーキングブレーキにはフットブレーキ操作が必要なので処理系が自動運転の方にくっついていて手動運転でもこれを利用する構成にしたように読める。他の手動装置の処理系は独立してたのでは
“なお、リセット処理時以外の自動運転システムの通信速度は250kbpsである” なんで今まで動いてたんやと思ったら
成長
停止方向への手動操作がオーバーライドされない自動運転システムは不味いな
なんのことか分からんが色々やって技術を進化させておくれ
この対応で大丈夫？他の何かで輻輳したら再発しそうだけど
通信で受信したリセット処理の破損データが、パーキング制御系を阻害したとすれば、車載ネットワークの構成がおかしい。そうでなく別のネットワークに分けられていたのなら、ブリッジへの攻撃として機能した？
まぁ、人命を犠牲にせず、EVMJ×先進モビリティの自動運転車は割とかなり不味かったとわかったのは収穫かもね…。大学発ベンチャーへの偏見が強まりそうだ私
CANなの？
バグでCANが輻輳→フットブレーキで停車状態になったことをシステムが検知できず→停車したのにパーキングブレーキが動作せず、か。