ホーム » パワートレイン構成とSysMLモデル » ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表す

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表す

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表す パワートレイン構成とSysMLモデル
2026.07.27

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表す

この記事で分かること

  • EV走行とエンジン走行の切替
  • 発電・駆動・回生の責務
  • 状態遷移条件
  • 要求図、BDD、IBD、状態機械図、検証ケースへの落とし込み方

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表すを実務で扱うとき、最初に避けたいのは「部品単体の説明」や「制御ロジック単体の説明」で終わらせることです。EV・ハイブリッド車では、電池、モータ、インバータ、熱管理、空調、充電、診断、運転者への表示が互いに影響します。ひとつの要求変更が、熱、電力、制御、安全、試験条件へ波及するためです。

特に電動パワートレインモデルでは、構成要素だけを描くと、エネルギー、トルク、熱、信号の流れが混ざり、変更影響を追えません。 そのため、SysMLを使って、要求、機能、構造、状態、検証を追跡できる形にしておくことが重要です。

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表すの要点は、きれいな図を作ることではなく、設計判断の根拠と影響範囲を追える状態にすることです。

目次

結論：電動パワートレインモデルは要求衝突を見える化する

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表すでは、バッテリー、インバータ、モータ、発電機、エンジン、減速機、ブレーキ協調、制御ECUをひとつの設計対象として見ます。ここでいう「ひとつ」とは、一枚の巨大な図に全部を詰め込むという意味ではありません。要求図で守るべき価値を置き、BDDで責務を分け、IBDで流れを分け、状態機械図で条件変化を表し、検証ケースで証拠へつなぐという意味です。

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表すのモデル関係

この整理をしておくと、レビューの論点が「性能を上げる」「電費を良くする」「安全を見る」といった抽象語だけで止まりません。どの条件で、どの部品が、どの制御により、どの検証で確認されるのかを追えるようになります。

観点EV・HVでの意味SysMLで確認すること
要求航続距離、燃費、快適性、安全、寿命、整備性上位要求と下位要求、優先順位、制約
機能駆動、発電、充電、熱管理、空調、診断機能分解、入出力、責務
構造電池、モータ、インバータ、熱交換器、ECUブロック、インターフェース、境界
状態走行、充電、休止、低温、高温、異常、復帰状態遷移、ガード条件、退避動作
検証台上、実車、ログ、FMEA、シミュレーション要求ID、試験条件、合否基準

なぜEV・HVではMBSEが効くのか

EV・HVは、機械だけでも電気だけでも制御ソフトだけでも成立しません。バッテリー温度が上がれば出力制限や充電制限が入り、暖房を強めれば航続距離に影響し、回生を増やせばブレーキ協調や乗り味に影響します。ハイブリッド車では、エンジン始動、モータ駆動、発電、回生、充電が状態によって切り替わります。

この複雑さを文章仕様書だけで管理すると、部門ごとに前提がずれやすくなります。MBSEの価値は、すべてを自動化することではありません。システム構成図、制御仕様、出力要求、熱要求、故障診断仕様、実車ログを要求や検証条件へ結び付け、変更時にどこへ影響するかを追えるようにすることです。

要求・構造・確認ポイント

項目設計での意味レビューで見ること
動力経路エンジン、モータ、発電機、減速機の関係を整理するトルクと回転数の流れを分ける
電力経路電池、インバータ、DCDC、補機を整理する高電圧系と低電圧系を分ける
熱経路モータ、インバータ、電池、冷却系をつなぐ温度制限と出力制限を対応させる
制御境界車両統合制御と各ECUの責務を置く指令とフィードバックを分ける
検証台上試験と実車状態を対応させるモードごとの合否基準を残す

この表は、最初の設計レビューでそのまま使える粒度を意識しています。各行に、担当部門、要求ID、根拠資料、未決事項、次に確認する試験を追記すると、SysMLモデルとレビュー議事録をつなぎやすくなります。

SysMLで表すモデル構成

SysMLでは、対象を図法ごとに分けます。要求図は「何を満たすか」、BDDは「何があるか」、IBDは「何が流れるか」、状態機械図は「いつ振る舞いが変わるか」、検証ケースは「どう確認するか」を扱います。

図使いどころEV・HVで入れる内容
要求図目的と制約を分ける航続距離、熱、出力、安全、快適性、寿命
BDD構成と責務を分ける電池、モータ、インバータ、空調、ECU、外部充電器
IBD流れを分ける電力、トルク、冷媒、冷却水、信号、診断データ
状態機械図条件で変わる動作を表す走行、充電、急速充電、低温、高温、異常、復帰
検証ケース証拠へつなぐ台上試験、実車試験、ログ確認、FMEA、シミュレーション

BDDで構成をそろえ、IBDで電力、熱、信号、トルクを分けると、部門間レビューの解像度が上がります。

設計レビューで使う確認表

確認項目レビュー質問証拠として見るもの
目的この記事のテーマで何を改善し、何を対象外にするか要求図、企画要求、性能目標
制約絶対に破ってはいけない条件は何か保護仕様、安全要求、快適性条件、法規・社内基準
入力どのセンサ、状態、外部情報を使うかBMSログ、温度、電流、電圧、車速、外気、充電情報
出力どの制御指令や表示へ反映するかECU仕様、警告表示、出力制限、充電制限、空調指令
異常時センサ異常、通信断、過熱、低信頼度でどう退避するか状態機械図、FMEA、診断仕様、縮退制御仕様
検証どの条件で合否と副作用を見るか台上試験、実車試験、ログ、シミュレーション、レビュー記録

レビューでは、正常時の性能だけでなく、異常時、低温時、高温時、劣化時、充電時、整備時も確認します。EV・HVの設計では、通常状態の最適化よりも、境界状態で安全側に動くこと、運転者や整備者へ説明できることが重要です。

エネルギー・トルク・回転数を分けた接続表

同じ「モータ」でも、駆動、回生、発電機による充電では符号と接続先が変わります。IBDでは電力と機械動力を別ポートにし、正方向を先に決めます。次の表は方式選定表ではなく、各モードで流れが閉じているかを調べるレビュー表です。

モード主な機械動力主な電力必須ガードレビューで残す証拠
EV走行モータ→減速機→車輪電池→インバータ→モータSOC、電池・インバータ・モータ温度、要求トルク軸トルク・回転数、DC電力、損失
エンジン走行エンジン→変速機→車輪補機電力または発電暖機、触媒、車速、変速状態燃料流量、軸動力、排気・冷却温度
協調駆動エンジン＋モータ→車輪電池→モータ合成トルク上限、回転同期、SOC要求値と各アクチュエータ実績値
発電・充電維持エンジン→発電機発電機→電池または駆動系充電受入れ電力、回転数、熱限界発電電力、SOC変化、燃料、温度
回生車輪→モータ／発電機インバータ→電池電池受入れ、タイヤ力、摩擦制動協調減速度、回生・摩擦配分、DC電力

故障時と復帰条件

トルク指令不一致、回転同期不能、DC電圧逸脱、温度上限接近、通信断を別イベントにします。検出時は、利用できる動力源と制動能力を評価してトルクを制限し、遷移理由を記録します。復帰は「DTCを消した」だけにせず、信号整合、温度余裕、電力収支、再同期完了を満たし、必要ならキーサイクルまたは整備確認を要求します。連続再試行の上限と、復帰できない場合の停止・警告を状態機械図に置きます。

検証条件とレビュー質問

検証では、`機械出力 = トルク[N·m] × 角速度[rad/s]` とDC側電力[kW]を同じ時刻基準で比較し、燃料投入、電池SOC変化、補機、熱損失を含む収支残差を確認します。低SOC、高SOC、低温、高温、勾配、急加減速、通信欠落を組み合わせ、モード切替前後のトルク段差と制動要求の欠落を観測します。

  • エンジン、各モータ／発電機、車輪の正トルク・正回転方向は統一されているか。
  • シリーズ、パラレル、動力分割のどの構成を前提にし、存在しない経路をモデルに混ぜていないか。
  • 充電受入れが下がったとき、回生制動の不足分をどの機能が受け持つか。
  • モード切替の合否を、効率だけでなくトルク連続性、温度、SOC、診断ログで判定できるか。

適用範囲と不確実性

この表はハイブリッド車の機能設計レビュー用です。実際の動力経路、クラッチ構成、モータ兼発電機の役割、許容値は車種固有です。DOE資料は代表的な構成理解には使えますが、日本の個別車両の適合や安全性を証明するものではありません。閾値は部品仕様、法規・規格の契約版、実機試験で確定します。

データ・AI・シミュレーションを扱う注意点

AIやシミュレーションを使う場合でも、要求が曖昧なままでは設計判断に使えません。入力データの周期、欠測、外れ値、センサ交換、車両差、季節差を定義し、モデルが有効な範囲と無効な範囲を分けます。

シミュレーションでは、境界条件を明記します。外気温、走行モード、SOC、SOH、乗員条件、空調設定、充電条件が変わると結果が変わります。結果をグラフで示すだけでなく、どの要求を検証したのか、どの制約を満たしたのか、実車試験との差分をどう扱うのかを残します。

AI制御や予兆診断では、説明ログと退避条件が必要です。AIが「異常の可能性あり」と判断した場合、どの入力が効いたのか、どの状態で判断したのか、誤検知時にどう復帰するのかを設計仕様へ入れます。これは研究用の補足ではなく、実車に接続するための要求です。

実務への落とし込み手順

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表すを現場で進める場合は、最初から全車両モデルを作ろうとしない方が定着します。次の順番で小さく始めると、設計レビューに使いやすくなります。

手順実施内容成果物
1対象状態を一つ選ぶ低温暖房、急速充電、回生、異常停止など
2上位要求を3から5個に絞る航続距離、出力、安全、快適性、寿命
3関係するブロックを置く電池、モータ、インバータ、空調、ECU、センサ
4入出力と状態遷移を確認する電力、熱、信号、診断、警告、退避
5検証条件を結び付ける台上試験、実車ログ、FMEA、シミュレーション
6未決事項を残す追加試験、センサ確認、制御変更、保守確認

この手順にすると、MBSEが「図を描く活動」ではなく、「設計判断を追跡する活動」になります。特にEV・HVでは、熱、電力、制御、安全の境界を早めに見える化するほど、後工程の手戻りを減らしやすくなります。

よくある失敗

1つ目の失敗は、航続距離、燃費、快適性、寿命、安全を別々の要求として扱い、相互の衝突を見ないことです。対策は、要求図で優先順位と制約を明記することです。

2つ目の失敗は、構成図だけを作り、電力、熱、冷媒、冷却水、信号、診断データの流れを分けないことです。対策は、IBDで流れの種類を分け、インターフェースごとに責任部門を置くことです。

3つ目の失敗は、正常時だけで制御を評価し、異常時、低温時、高温時、劣化時、通信断の退避条件を後回しにすることです。対策は、状態機械図で通常、制限、異常、停止、復帰を分けることです。

4つ目の失敗は、シミュレーションやAIの結果を要求IDへ結び付けないことです。対策は、モデル結果、試験結果、ログを検証ケースへ接続し、判断に使った条件を残すことです。

次に読むなら

次に読むなら、EVパワートレインをBDDで整理する：バッテリー、インバータ、モータ、減速機 がおすすめです。前提を押さえると、この設計判断の位置づけがつかみやすくなります。

関連記事

参考資料

まとめ

ハイブリッド車のエンジン・モータ・発電機の関係をSysMLで表すでは、個別部品や単独制御ではなく、要求、機能、構造、状態、データ、検証条件をつなげて考えることが重要です。EV・ハイブリッド車は、電池、モータ、インバータ、熱管理、空調、充電、診断、整備が相互に影響するシステムです。

SysMLは、複雑な設計を抽象化して終わるための道具ではありません。設計判断、試験、FMEA、シミュレーション、実車ログを同じ前提へ戻すための実務ツールです。まずは一つの状態、一つの要求、一つのレビュー表から始め、影響範囲を追える形にしていくことが現実的です。

コメント

タイトルとURLをコピーしました