この記事で分かること
- EV走行とエンジン走行の切替
- 発電・駆動・回生の責務
- 状態遷移条件
- 要求図、BDD、IBD、状態機械図、検証ケースへの落とし込み方
ハイブリッド車の燃費・走行性能・耐久性を要求図で整理する方法を実務で扱うとき、最初に避けたいのは「部品単体の説明」や「制御ロジック単体の説明」で終わらせることです。EV・ハイブリッド車では、電池、モータ、インバータ、熱管理、空調、充電、診断、運転者への表示が互いに影響します。ひとつの要求変更が、熱、電力、制御、安全、試験条件へ波及するためです。
特に電動車MBSEでは、航続距離や燃費だけを単独要求にすると、熱、制御、安全、品質の制約が後から衝突します。 そのため、SysMLを使って、要求、機能、構造、状態、検証を追跡できる形にしておくことが重要です。
ハイブリッド車の燃費・走行性能・耐久性を要求図で整理する方法の要点は、きれいな図を作ることではなく、設計判断の根拠と影響範囲を追える状態にすることです。
目次
- 結論：電動車MBSEは要求衝突を見える化する
- なぜEV・HVではMBSEが効くのか
- 要求・構造・確認ポイント
- SysMLで表すモデル構成
- 設計レビューで使う確認表
- 燃費・性能・耐久を同じ評価点で比べる
- データ・AI・シミュレーションを扱う注意点
- 実務への落とし込み手順
- よくある失敗
- 参考資料
- まとめ
結論：電動車MBSEは要求衝突を見える化する
ハイブリッド車の燃費・走行性能・耐久性を要求図で整理する方法では、車両要求、電池、モータ、熱、制御、検証、部門間レビューをひとつの設計対象として見ます。ここでいう「ひとつ」とは、一枚の巨大な図に全部を詰め込むという意味ではありません。要求図で守るべき価値を置き、BDDで責務を分け、IBDで流れを分け、状態機械図で条件変化を表し、検証ケースで証拠へつなぐという意味です。
この整理をしておくと、レビューの論点が「性能を上げる」「電費を良くする」「安全を見る」といった抽象語だけで止まりません。どの条件で、どの部品が、どの制御により、どの検証で確認されるのかを追えるようになります。
| 観点 | EV・HVでの意味 | SysMLで確認すること |
|---|---|---|
| 要求 | 航続距離、燃費、快適性、安全、寿命、整備性 | 上位要求と下位要求、優先順位、制約 |
| 機能 | 駆動、発電、充電、熱管理、空調、診断 | 機能分解、入出力、責務 |
| 構造 | 電池、モータ、インバータ、熱交換器、ECU | ブロック、インターフェース、境界 |
| 状態 | 走行、充電、休止、低温、高温、異常、復帰 | 状態遷移、ガード条件、退避動作 |
| 検証 | 台上、実車、ログ、FMEA、シミュレーション | 要求ID、試験条件、合否基準 |
なぜEV・HVではMBSEが効くのか
EV・HVは、機械だけでも電気だけでも制御ソフトだけでも成立しません。バッテリー温度が上がれば出力制限や充電制限が入り、暖房を強めれば航続距離に影響し、回生を増やせばブレーキ協調や乗り味に影響します。ハイブリッド車では、エンジン始動、モータ駆動、発電、回生、充電が状態によって切り替わります。
この複雑さを文章仕様書だけで管理すると、部門ごとに前提がずれやすくなります。MBSEの価値は、すべてを自動化することではありません。企画要求、性能目標、電費・燃費試験、熱評価、過去不具合、制御仕様書を要求や検証条件へ結び付け、変更時にどこへ影響するかを追えるようにすることです。
要求・構造・確認ポイント
| 項目 | 設計での意味 | レビューで見ること |
|---|---|---|
| 上位要求 | 航続距離、燃費、出力、快適性、安全を並べる | 数値、条件、優先順位を分ける |
| システム境界 | 車両、充電器、外気、運転者、整備を含める | 対象外も明記する |
| 構成要素 | 電池、モータ、インバータ、熱管理、ECUを置く | 責任部門を対応させる |
| 状態 | 走行、充電、休止、異常、整備を分ける | 状態ごとの要求を確認する |
| 検証 | 台上、実車、ログ、故障診断をつなぐ | 要求IDと証拠を対応させる |
この表は、最初の設計レビューでそのまま使える粒度を意識しています。各行に、担当部門、要求ID、根拠資料、未決事項、次に確認する試験を追記すると、SysMLモデルとレビュー議事録をつなぎやすくなります。
SysMLで表すモデル構成
SysMLでは、対象を図法ごとに分けます。要求図は「何を満たすか」、BDDは「何があるか」、IBDは「何が流れるか」、状態機械図は「いつ振る舞いが変わるか」、検証ケースは「どう確認するか」を扱います。
| 図 | 使いどころ | EV・HVで入れる内容 |
|---|---|---|
| 要求図 | 目的と制約を分ける | 航続距離、熱、出力、安全、快適性、寿命 |
| BDD | 構成と責務を分ける | 電池、モータ、インバータ、空調、ECU、外部充電器 |
| IBD | 流れを分ける | 電力、トルク、冷媒、冷却水、信号、診断データ |
| 状態機械図 | 条件で変わる動作を表す | 走行、充電、急速充電、低温、高温、異常、復帰 |
| 検証ケース | 証拠へつなぐ | 台上試験、実車試験、ログ確認、FMEA、シミュレーション |
最初のモデルは車両全体を細かく描くより、要求衝突が起きやすい熱、電力、制御、安全の境界を見える化することに価値があります。
設計レビューで使う確認表
| 確認項目 | レビュー質問 | 証拠として見るもの |
|---|---|---|
| 目的 | この記事のテーマで何を改善し、何を対象外にするか | 要求図、企画要求、性能目標 |
| 制約 | 絶対に破ってはいけない条件は何か | 保護仕様、安全要求、快適性条件、法規・社内基準 |
| 入力 | どのセンサ、状態、外部情報を使うか | BMSログ、温度、電流、電圧、車速、外気、充電情報 |
| 出力 | どの制御指令や表示へ反映するか | ECU仕様、警告表示、出力制限、充電制限、空調指令 |
| 異常時 | センサ異常、通信断、過熱、低信頼度でどう退避するか | 状態機械図、FMEA、診断仕様、縮退制御仕様 |
| 検証 | どの条件で合否と副作用を見るか | 台上試験、実車試験、ログ、シミュレーション、レビュー記録 |
レビューでは、正常時の性能だけでなく、異常時、低温時、高温時、劣化時、充電時、整備時も確認します。EV・HVの設計では、通常状態の最適化よりも、境界状態で安全側に動くこと、運転者や整備者へ説明できることが重要です。
燃費・性能・耐久を同じ評価点で比べる
三つの要求は別試験で合格させるだけでなく、同じ制御変更が各要求へ与える影響を一つの表で追います。要求図では「改善する」ではなく、測定量、境界条件、判定方法、検証ケースを要求属性にします。
| 要求群 | 測定量と単位の例 | 固定する境界条件 | 競合しやすい設計判断 | 検証証拠 |
|---|---|---|---|---|
| 燃費・エネルギー | 燃料量[L]、電力量[kWh]、距離[km] | 走行サイクル、SOC補正、外気、空調、積載 | 高負荷運転点、充放電、暖機 | シャシ試験、燃料・DC電力・SOCログ |
| 動力性能 | 加速時間[s]、登坂速度[km/h]、車輪出力[kW] | 車重、勾配、SOC、温度、連続／瞬時 | 電池出力と熱余裕の消費 | 台上・実車のトルク、回転数、温度 |
| 耐久 | 累積時間[h]、熱サイクル数、電流・トルク履歴 | 寿命プロファイル、部品温度、振動、劣化状態 | 高出力頻度、始動停止頻度、冷却余裕 | 加速耐久、分解調査、故障・劣化ログ |
パラメトリック図では、燃料、電池電力、車輪仕事、損失、熱を同じ計算境界へ置きます。重み付き一指標へ早く集約すると衝突が隠れるため、まず要求ごとの余裕と悪化量を並べ、利害関係者が重みと許容差を承認してからトレードオフを決めます。
失敗・復帰と変更停止条件
典型的な失敗は、燃費校正で電池・インバータ温度や始動回数を増やす、性能校正で耐久プロファイル外の電流を常用する、SOC補正の違いで比較を誤ることです。境界条件や計測品質が一致しない比較は判定保留とし、元の校正へ戻せる構成IDを残します。回帰試験で三要求すべての余裕が確認できるまで量産判断へ進めません。
検証条件とレビュー質問
基準校正と変更校正を同じ車両状態、走行サイクル、外気、空調、積載、初期SOCで比較し、試験間のSOC差とエネルギー収支を補正します。公称条件だけでなく、低高温、劣化、低高SOC、連続登坂、渋滞を含め、瞬時性能と累積損傷指標を同じ実験IDへ結びます。
- 三要求の測定境界、単位、初期条件は一致しているか。
- 公式燃費値と開発用の比較指標を混同していないか。
- 高出力の許容時間と、その後の温度・出力復帰条件を検証できるか。
- 校正変更による改善量と、耐久・排気・NVHの悪化量を同じ版で比較できるか。
適用範囲と不確実性
EPAの試験説明は米国の表示・認証方法に関する資料で、日本その他の法域へそのまま適用できません。耐久の負荷履歴と合否基準は部品、用途、地域、契約仕様に依存します。シミュレーション結果は入力分布とモデル妥当性の範囲内の推定であり、認証値や寿命保証を単独で証明しません。
データ・AI・シミュレーションを扱う注意点
AIやシミュレーションを使う場合でも、要求が曖昧なままでは設計判断に使えません。入力データの周期、欠測、外れ値、センサ交換、車両差、季節差を定義し、モデルが有効な範囲と無効な範囲を分けます。
シミュレーションでは、境界条件を明記します。外気温、走行モード、SOC、SOH、乗員条件、空調設定、充電条件が変わると結果が変わります。結果をグラフで示すだけでなく、どの要求を検証したのか、どの制約を満たしたのか、実車試験との差分をどう扱うのかを残します。
AI制御や予兆診断では、説明ログと退避条件が必要です。AIが「異常の可能性あり」と判断した場合、どの入力が効いたのか、どの状態で判断したのか、誤検知時にどう復帰するのかを設計仕様へ入れます。これは研究用の補足ではなく、実車に接続するための要求です。
実務への落とし込み手順
ハイブリッド車の燃費・走行性能・耐久性を要求図で整理する方法を現場で進める場合は、最初から全車両モデルを作ろうとしない方が定着します。次の順番で小さく始めると、設計レビューに使いやすくなります。
| 手順 | 実施内容 | 成果物 |
|---|---|---|
| 1 | 対象状態を一つ選ぶ | 低温暖房、急速充電、回生、異常停止など |
| 2 | 上位要求を3から5個に絞る | 航続距離、出力、安全、快適性、寿命 |
| 3 | 関係するブロックを置く | 電池、モータ、インバータ、空調、ECU、センサ |
| 4 | 入出力と状態遷移を確認する | 電力、熱、信号、診断、警告、退避 |
| 5 | 検証条件を結び付ける | 台上試験、実車ログ、FMEA、シミュレーション |
| 6 | 未決事項を残す | 追加試験、センサ確認、制御変更、保守確認 |
この手順にすると、MBSEが「図を描く活動」ではなく、「設計判断を追跡する活動」になります。特にEV・HVでは、熱、電力、制御、安全の境界を早めに見える化するほど、後工程の手戻りを減らしやすくなります。
よくある失敗
1つ目の失敗は、航続距離、燃費、快適性、寿命、安全を別々の要求として扱い、相互の衝突を見ないことです。対策は、要求図で優先順位と制約を明記することです。
2つ目の失敗は、構成図だけを作り、電力、熱、冷媒、冷却水、信号、診断データの流れを分けないことです。対策は、IBDで流れの種類を分け、インターフェースごとに責任部門を置くことです。
3つ目の失敗は、正常時だけで制御を評価し、異常時、低温時、高温時、劣化時、通信断の退避条件を後回しにすることです。対策は、状態機械図で通常、制限、異常、停止、復帰を分けることです。
4つ目の失敗は、シミュレーションやAIの結果を要求IDへ結び付けないことです。対策は、モデル結果、試験結果、ログを検証ケースへ接続し、判断に使った条件を残すことです。
次に読むなら
次に読むなら、EVの仕様書をSysML要求図へ変換する方法 がおすすめです。前提を押さえると、この設計判断の位置づけがつかみやすくなります。
関連記事
- ハイブリッド車の複雑さをSysMLで整理する基本手順: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
- EVとHEVのシステム構成をMBSE視点で比較する: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
- EV開発にMBSEが必要になる理由：電池・モータ・熱・制御が分断されるリスク: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
- EVの要求定義を「航続距離」だけで終わらせないためのMBSE入門: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
参考資料
- U.S. EPA: Fuel Economy and EV Range Testing（確認日: 2026-09-04）
- Argonne National Laboratory: Autonomie（確認日: 2026-09-04）
- U.S. DOE: Electric Drive Systems Research and Development（確認日: 2026-09-04）
- OMG Systems Modeling Language Version 1.6（確認日: 2026-09-04）
まとめ
ハイブリッド車の燃費・走行性能・耐久性を要求図で整理する方法では、個別部品や単独制御ではなく、要求、機能、構造、状態、データ、検証条件をつなげて考えることが重要です。EV・ハイブリッド車は、電池、モータ、インバータ、熱管理、空調、充電、診断、整備が相互に影響するシステムです。
SysMLは、複雑な設計を抽象化して終わるための道具ではありません。設計判断、試験、FMEA、シミュレーション、実車ログを同じ前提へ戻すための実務ツールです。まずは一つの状態、一つの要求、一つのレビュー表から始め、影響範囲を追える形にしていくことが現実的です。
コメント