|
27 |
バックカメラのリコールについて |
バックカメラのリコールについての表を入手しました。
これについてChatGPTにテストケースを洗い出して貰ったところ、以下のような回答を得ました。
表の内容から見ると、共通する故障モードは次の5系統です。
- 起動中・終了中・再起動中の状態遷移不良
- 低電圧・電圧スパイク・I2Cノイズへの耐性不足
- カメラ映像・通信断への例外処理不足
- 画像処理負荷ピークによるメモリ破壊・バッファオーバーフロー
- 不正または極端な設定値の永続化による表示不能
したがって、開発段階では「正常動作確認」ではなく、起動・終了・電源変動・通信断・高負荷・異常設定値を組み合わせた破壊的テストが必要です。
洗い出すべきテストケース
| ID | テストケース | 刺激条件 | 期待結果 |
|---|---|---|---|
| TC-01 | 高密度ADAS対象物による画像処理ピーク負荷試験 | 都市部、交差点、歩行者、自転車、車両、標識を大量に含むシミュレーション映像を入力 | フレーム落ち、遅延、メモリ増加、バッファオーバーフローが発生しない |
| TC-02 | 画像処理バッファ上限試験 | 最大解像度、最大フレームレート、最大物体数、複数カメラ同時入力 | メモリ境界を超えず、超過時は安全にドロップまたは縮退する |
| TC-03 | 長時間高負荷ソーク試験 | TC-01相当の負荷を数時間から数十時間連続実行 | メモリリーク、ヒープ断片化、遅延蓄積、クラッシュがない |
| TC-04 | I2C電圧スパイク注入試験 | 起動中にI2Cラインへ短時間スパイク、グリッチ、ノイズを注入 | レジスタ値が破壊されず、異常値は検出・再初期化される |
| TC-05 | 表示マイコン起動中ノイズ試験 | ディスプレイMCU初期化中にI2C/SPI/CAN/LIN通信へノイズを重畳 | 画面ブラックアウト、フリーズ、誤設定保持が発生しない |
| TC-06 | 低電圧ブラウンアウト試験 | クランキング相当の電圧低下を起動直後、カメラ接続直後、リバース投入直後に発生させる | 電圧復帰後に自動復旧し、ユーザー操作なしで映像表示に戻る |
| TC-07 | 電源瞬断・再投入試験 | 電源ON直後、シャットダウン中、カメラ起動中に電源を瞬断して再投入 | 不完全な状態が残らず、次回起動時に正常初期化される |
| TC-08 | 急速イグニッションサイクル試験 | OFF→ACC→ON→OFF→ONを短時間で連続実施 | sleep/wakeのデッドロック、タイマ未起動、タスク停止が起こらない |
| TC-09 | シャットダウン未完了中の再起動試験 | システム終了処理中に再度電源ONまたはリバース投入 | 前回状態を引きずらず、状態機械が初期状態から再構成される |
| TC-10 | 起動中リバース投入試験 | ECU、ヘッドユニット、カメラ、駐車支援モジュールの起動完了前にRレンジへ投入 | カメラ映像または代替警告が規定時間内に表示される |
| TC-11 | リバース高速切替試験 | P→R→D→R、N→R→Pなどを短時間で繰り返す | 状態機械が禁止遷移や未初期化状態に入らない |
| TC-12 | 起動中の不正順序イベント試験 | カメラ準備完了前にリバース要求、表示準備前に映像入力、通信確立前に描画要求を発生 | イベントをキューイング、破棄、再試行のいずれかで安全に処理する |
| TC-13 | カメラ映像通信断試験 | カメラ映像ストリームを一時停止、パケットドロップ、リンク断、再接続 | ヘッドユニットがクラッシュせず、再接続後に自動復帰する |
| TC-14 | カメラ通信遅延・ジッタ試験 | フレーム周期を乱し、遅延フレーム、欠落フレーム、順序逆転を発生 | 古いフレームを誤表示せず、タイムアウト処理が働く |
| TC-15 | 通信線切断・復帰試験 | カメラ、表示ECU、ヘッドユニット間の通信を走行・停止・リバース中に切断復帰 | 表示が固着せず、フェイル表示または復旧処理に移行する |
| TC-16 | 極端な輝度・コントラスト設定試験 | 明度、コントラスト、ガンマ、バックライト値を最小・最大・範囲外に設定 | 画面が完全に読めない状態にならず、規定のフォールバック値に戻る |
| TC-17 | 設定値永続化境界試験 | 異常値、破損NVM値、旧バージョン設定値を起動時に読み込ませる | 範囲チェック後にデフォルト値へ戻り、ブラックスクリーンにならない |
| TC-18 | 設定値リセット試験 | 表示不能に近い設定を保存後、次回起動 | 規制上必要な表示が見える値へ自動補正される |
| TC-19 | ウォッチドッグ・タスク監視試験 | 画像処理、通信、表示、状態管理タスクを意図的に停止または遅延 | ウォッチドッグが検出し、再起動または縮退動作に入る |
| TC-20 | エラー処理分岐カバレッジ試験 | 電圧低下、通信断、メモリ不足、タイムアウトを個別・同時に注入 | すべての例外分岐が実行され、未処理例外で停止しない |
| TC-21 | 起動時間最悪条件試験 | 低温、高温、低電圧、高負荷、NVM読み出し遅延を同時に与える | 起動時間が要求値を超えず、超える場合は安全な中間表示を出す |
| TC-22 | 量産差・劣化模擬試験 | バッテリ劣化、ケーブル抵抗増加、コネクタ接触不良を模擬 | 現実的な劣化条件でもリバース映像が失われない |
| TC-23 | ソフトウェア更新後の設定互換性試験 | 旧バージョンから新バージョンへ更新し、古い設定値を読み込む | データ変換に失敗しても安全な初期値で起動する |
| TC-24 | 複合シナリオ試験 | シャットダウン未完了直後に再始動し、低電圧中にRレンジ投入、同時にカメラ通信遅延 | 状態機械が破綻せず、表示不能または誤表示が継続しない |
特に重要なシナリオ
表のリコール事例を見ると、単独の異常よりも、次のような組合せ条件が危険です。
$$ \text{起動中} + \text{低電圧} + \text{リバース投入} $$
$$ \text{シャットダウン未完了} + \text{再起動} + \text{状態保持} $$
$$ \text{高負荷画像処理} + \text{メモリ上限} + \text{例外処理不足} $$
$$ \text{通信断} + \text{再接続} + \text{表示タスク復旧} $$
このため、テスト設計としては、単体テストだけでなく、HILで電源・通信・シフト操作・カメラ入力を同期的に乱すテストを入れるべきです。
最低限の開発ゲート
開発完了判定には、少なくとも次を入れるべきです。
| ゲート | 判定内容 |
|---|---|
| メモリ安全性 | バッファ境界、メモリリーク、長時間高負荷で異常なし |
| 電源ロバスト性 | ブラウンアウト、瞬断、再投入で自動復旧 |
| 状態機械健全性 | 禁止遷移、未初期化状態、デッドロックなし |
| 通信異常耐性 | カメラ通信断、遅延、パケット欠落でクラッシュなし |
| 表示安全性 | ブラックスクリーン、極端な表示設定、古い映像固着なし |
| 復旧性 | 異常後にユーザー操作なしで正常状態へ復帰 |
| 複合異常耐性 | 電源異常、通信異常、リバース操作の同時発生に耐える |
結論として、この表から導かれる開発テストの中心は、リバースカメラや駐車支援システムを、起動・終了・低電圧・通信断・高負荷の境界条件で壊しに行くテストです。正常な走行状態で映ることを確認するだけでは不十分です。
前のブログ
