統合制御ECUのIBDは信号線図ではなく、各ポートの意味・単位・範囲・周期・遅延・新鮮度・品質・権限・timeout時動作まで含むインターフェース契約にします。要求値・許可値・実績値を分け、複数ECUの指令競合をarbiterで明示します。
BMSの許容放電電力、運転者の要求トルク、熱制御のデレート、ADASの加減速要求が統合ECUへ入る場面では、全部を『トルク要求』として束ねると権限と優先順位が消えます。source、validity、reason、timestampを伴う別ポートとして扱います。
この記事で分かること
- IBDを信号契約へ変える属性
- 要求・許可・実績の分離
- 指令競合とarbiterの設計
- 通信異常・再同期・復帰の検証
目次
- 結論：車両エネルギーマネジメントは要求衝突を見える化する
- なぜEV・HVではMBSEが効くのか
- 要求・構造・確認ポイント
- SysMLで表すモデル構成
- 設計レビューで使う確認表
- データ・AI・シミュレーションを扱う注意点
- 実務への落とし込み手順
- よくある失敗
- まとめ
結論：車両エネルギーマネジメントは要求衝突を見える化する
統合制御ECUのIBDは信号線図ではなく、各ポートの意味・単位・範囲・周期・遅延・新鮮度・品質・権限・timeout時動作まで含むインターフェース契約にします。要求値・許可値・実績値を分け、複数ECUの指令競合をarbiterで明示します。
| ポート種別 | 例 | 契約属性 | timeout時 |
|---|---|---|---|
| Request | 運転者/ADASトルク要求 | 単位、範囲、優先度、valid | 無効化または保持制限 |
| Limit | BMS/熱/安全の上限 | 適用方向、理由、新鮮度 | 保守上限 |
| Command | モータ/ブレーキ指令 | 所有者、rate limit、counter | 安全側指令 |
| Feedback | 実トルク/電力/状態 | 精度、遅延、quality | 診断・縮退 |
| Diagnostic | DTC/health/heartbeat | latched、severity、timestamp | 故障状態へ遷移 |
この表の各行には、要求ID、モデル要素ID、担当、根拠版、未決事項、検証ケースIDを付けます。図上で線がつながっていても、条件・単位・版が欠けていれば、変更影響や合否を再現できません。
なぜEV・HVではMBSEが効くのか
BMSの許容放電電力、運転者の要求トルク、熱制御のデレート、ADASの加減速要求が統合ECUへ入る場面では、全部を『トルク要求』として束ねると権限と優先順位が消えます。source、validity、reason、timestampを伴う別ポートとして扱います。
対象を文章仕様だけで管理すると、要求、設計値、制御状態、試験結果の版がずれやすくなります。MBSEの役割は図を増やすことではなく、設計判断の入力・出力・根拠・責任を関係として管理し、変更後も検証証拠へ戻れるようにすることです。
要求・構造・確認ポイント
| 要求ID | 検証可能な要求 | 主な設計要素 | 証拠 |
|---|---|---|---|
| REQ-IBD-01 | 全ポートに型・単位・範囲・時刻を定義 | interface dictionary | 自動schema検査 |
| REQ-IBD-02 | 指令権と優先順位を一意にする | arbiter | 競合シナリオ試験 |
| REQ-IBD-03 | timeout/invalid時に決定論的fallback | 状態機械 | 故障注入 |
| REQ-IBD-04 | 復帰で古い指令を再利用しない | counter/timestamp/resync | 再接続試験 |
SysMLで表すモデル構成
SysMLでは、要求図で目的と制約を分け、BDDで責務、IBDで物理量と信号、状態機械図でガード・縮退・復帰、パラメトリック図で制約式を表します。satisfy は設計要素、verify は検証ケースへ結び、単なる関連線と混同しません。
最終トルク指令を概念的に `T_cmd = clamp(T_request, T_lower, T_upper)` とし、上限候補の最小値、下限候補の最大値、優先順位、rate limitを別要素にします。符号と回生方向をインターフェース辞書で固定します。
計算例として、運転要求200 N·m、BMS上限150 N·m、熱上限120 N·m、安全上限100 N·mなら出力は100 N·mです。ログには最終値だけでなく支配制約、安全上限の版、入力時刻を保存します。
計算値は桁数より前提が重要です。入力値の測定点、時間同期、サンプリング周期、フィルタ、許容差、モデル版を結果と一緒に保存します。
設計レビューで使う確認表
- 要求値と許可上限と実績値を同じ信号にしていないか
- 複数ECUが同じアクチュエータを直接指令していないか
- 回生/駆動の符号と単位が一意か
- timeoutと周期を混同していないか
- 復帰時に古い指令や状態を再利用しないか
- 最終指令の支配理由をログから説明できるか
質問には、回答者、根拠ファイル、適用版、未決時の暫定措置を付けます。「確認済み」だけでは、後から判断根拠を再現できません。
データ・AI・シミュレーションを扱う注意点
| 状態 | 進入・成立条件 | 制御・制限 | 解除・次状態 |
|---|---|---|---|
| Synchronized | 全必須IFが新鮮で整合 | 通常arbiter | 欠損でDegraded |
| Degraded | 一部IF timeout/invalid | 保守上限と機能制限 | 連続整合でResync |
| Resync | counter・状態・時刻を再同期 | 出力をrate limit | 合格でSynchronized |
| FailSilent/Safe | 重要IF不整合 | 指令停止または安全側 | 整備/再起動条件で復帰 |
正常、候補、制限、保護を分けると、単発ノイズで強い制限へ入ることと、異常を見逃すことの両方をレビューできます。復帰にはヒステリシス、連続正常時間、再発時のラッチを必要に応じて定義します。
実務への落とし込み手順
1. 車両ユースケースと指令権を先に定義する 2. ECU、センサ、アクチュエータをBDDへ置く 3. IBDポートをRequest/Limit/Command/Feedback/Diagnosticへ分類する 4. 信号辞書へ単位・範囲・周期・遅延・quality・timeoutを付ける 5. arbiterと状態機械で競合・欠損・復帰を定義する 6. 通信故障、古い値、順序逆転、境界トルクをHILで検証する
各手順の完了条件をファイル作成ではなく、次工程が判断できる証拠で定義します。未決事項は消さず、所有者、期限、影響する要求と試験を記録します。
| ID | 目的 | 条件・入力 | 確認量 |
|---|---|---|---|
| V-IBD-01 | 競合 | 複数request/limit同時変化 | 優先順位と理由 |
| V-IBD-02 | timeout | 各IFを単独/複合遮断 | fallbackと遷移時間 |
| V-IBD-03 | 再同期 | counterずれ・古いtimestamp | 誤指令なし |
| V-IBD-04 | 境界 | min/max/rate limit | 飽和と連続性 |
正常一点だけでなく、境界値の前後、ばらつき、劣化、通信遅れ、センサ故障、復帰を組み合わせます。合否基準と併せて、観測できない量を何で推定するかも明記します。
よくある失敗
| 失敗 | なぜ問題か | 対策 |
|---|---|---|
| 矢印だけのIBD | 意味・時刻・権限がない | ポート契約を属性化 |
| 最終値だけログ | 支配制約が不明 | reason/source/versionを保存 |
| last value無期限保持 | 古い許可値で制御 | Ageと保持上限 |
| 復帰即通常 | 状態不整合で急変 | Resyncとrate limit |
適用範囲と不確実性
信号名・優先順位・timeout値は車両固有です。IBDは通信規格や機能安全設計を置き換えません。サイバーセキュリティ、ASIL、ネットワーク負荷、E2E保護は正式な車両設計で評価してください。
規格・ガイドラインは適用範囲と最新版を案件ごとに確認し、公開ページの要約だけで適合を判定しません。安全関連の要求値、故障許容時間、診断カバレッジ、法規適用は、車両固有の分析と承認済み資料を正とします。
次に読むなら
次に読むなら、EVのエネルギーマネジメント要求をSysMLで整理する がおすすめです。前提を押さえると、この設計判断の位置づけがつかみやすくなります。
関連記事
- PHEVのEV走行とHV走行の切替条件をSysMLで整理する: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
- SOC、SOH、温度、出力制限の関係をパラメトリック図で整理する: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
- 充電制御と走行制御のインターフェースをSysMLで表す: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
- 回生ブレーキ制御の要求・状態・検証をつなぐ方法: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
参考資料
- OMG Systems Modeling Language Version 1.6（確認日: 2026-09-05）
- NASA Systems Modeling Handbook for Systems Engineering（確認日: 2026-09-05）
- ISO 26262-10:2018 Guidelines on functional safety（確認日: 2026-09-05）
- NHTSA: Cybersecurity Best Practices for the Safety of Modern Vehicles（確認日: 2026-09-05）
まとめ
統合ECUのIBDで重要なのは接続数ではなく、誰の値がいつ有効で、競合時に何が勝ち、欠損後にどう安全に戻るかです。支配理由までログ化すると設計・故障解析がつながります。
コメント