自動化統合の突破がEV制御開発を加速
ミリ秒単位の差が最適な性能とシステムの遅延を分ける領域において、電気自動車（EV）開発の効率化を目指す競争はかつてない緊急性を帯びている。電動化が自動車業界を再構築する中、エンジニアはより速く革新するだけでなく、信頼性と安全性を保ちながら規模を拡大することにも大きなプレッシャーを受けている。こうした背景の下、『重慶理工大学学报（自然科学版）』（Journal of Chongqing University of Technology (Natural Science)）に掲載された研究で明らかにされた新しい方法論が、開発期間の短縮、人的ミスの削減、複雑な制御ロジックの実世界ハードウェアへの標準化された統合を約束するとして、学界と産業界の双方から真剣な注目を集めている。
この革新の核心は、高水準の制御戦略設計と低水準の組み込みドライバー設定という、歴史的に頑なに分断されたままだった二つの領域のシームレスな融合にある。従来、純粋電気自動車の「頭脳」である車両制御ユニット（VCU）の開発は、V字モデルのワークフローに従ってきた。エンジニアはアプリケーション層の制御ロジック（トルク調停、ギアシフトロジックなど）を設計し、徹底的にシミュレーションし、（多くの場合MATLAB/Simulinkを用いて）コードを自動生成した後、そのロジックをSTM32シリーズのようなマイクロコントローラー向けに個別にコーディングされた低レベルのハードウェアドライバーに手作業で組み込んでいく。この最終的な統合作業は、変数の不一致、バージョンのずれ、手入力の誤りに満ちており、長らくボトルネックとなってきた。
新たに提案されたアプローチはこの常識を覆す。アプリケーションコードとドライバーコードを別々の環境で生成する代わりに、南京航空航天大学エネルギー・動力工程学院のシェン・フアン（Shen Huan）、マオ・ジエングォ（Mao Jianguo）、ジョウ・フーリャン（Zhou Fuliang）、チェン・ウェイ（Chen Wei）、ヤン・ジーウェイ（Yan Zhiwei）らによる研究チームは、完全に共同シミュレーションされ、共同生成されるワークフローを実証した。彼らの方法は、STMicroelectronicsとMathWorksの二つの密接に連携したツール、STM32CubeMXとSTM32-MAT/TARGET（後者はチップレベルの周辺機器設定をドラッグ＆ドロップ可能なSimulinkブロックに変換する公式Simulink統合パッケージ）を活用している。
こう考えればわかりやすい。以前、現代的なVCUを構築するのは、高性能スポーツカーを二つの別々のガレージで組み立てるようなものだった。一つはエンジンとトランスミッション用、もう一つはシャシーと電子機器用。エンジニアは行き来を繰り返し、マウントポイントやワイヤーハーネスが合うことを願っていた。今、このワークフローを用いれば、エンジン、ECU、センサー、アクチュエーターのすべてが一つの統一された環境でモデリング、シミュレーション、コンパイルされ、まるで車両全体が同期された一つの組立ラインからロールオフするかのようだ。
その意味合いは、効率性だけでなく、安全性と拡張性においても大きい。
実際の現場でこれがどのように見えるかを詳しく見てみよう。研究者たちは、自動車のプロトタイピングや中間層の生産用ECUで広く使用されている32ビットARM Cortex-M4マイクロコントローラー、STM32F407ZGT6を選択した。アナログ-デジタル変換器（ADC）、汎用入出力（GPIO）、UART通信などのためのレジスタレベルのCコードを書く代わりに、彼らはまずSTM32CubeMX内で、ピン割り当て、クロックツリー、サンプリングレート、割り込み優先度などすべてのハードウェア周辺機器を視覚的に設定した。エクスポートされると、その設定はADC_Read、GPIO_Read、UART_TXなどのすぐに使用可能なブロックのライブラリとしてSimulinkに自動的にインポートされた。
これらのブロックはスタブやプレースホルダーではなく、実際のハードウェアドライバーの機能的に正確な表現であった。これは、チームが車両の電源投入/遮断シーケンス、ギア状態管理、ペダル信号の解釈、トルク調停などの重要な機能をカバーするアプリケーション層のロジックを構築する際、同じモデリングキャンバス内で、実際のセンサー入力（アクセルペダル位置、ブレーキ状態、ギアセレクター信号など）をアルゴリズムブロックに直接配線できることを意味した。データ型やスケーリング係数を推測する必要はなく、バッファサイズの不一致や初期化呼び出しの見落としもなくなった。
この戦略の特に優れた点は、EV制御の特に難しい側面である状態シーケンスをどのように扱うかにある。車両の電源投入プロセスを考えてみよう。悲惨なアーク放電やバッテリー管理システム（BMS）、モーターインバーターのような敏感な電子機器への損傷を防ぐため、「まず低電圧、その後高電圧」という厳格な順序に従わなければならない。従来のワークフローでは、このシーケンスは手続き的にコーディングされるだろう。一連のif-elseチェック、タイマートリガー、フラグの切り替えであり、可視化が難しく、検証はさらに難しかった。
ここでは、チームは電源投入/遮断の流れをSimulinkに組み込まれた状態機械としてモデル化し、遷移は論理条件だけでなく、仮想ドライバー層から引き出されたリアルタイムのハードウェア信号によっても支配されるようにした。例えば、シミュレートされた「KEY_ON」GPIO信号がハイになったとき、モデルはVCUをトリガーしてBMSを（仮想CANまたは離散信号を介して）起動し、「BMS_OK」ハンドシェイク（このプロトタイプでは定数0としてシミュレート）を待ち、その後プリチャージリレーを作動させた。システムはシミュレートされた「コントローラー電圧」（分圧器の読み取りを模倣するADCブロックから供給）を継続的に監視し、コントローラーとバッテリー間の電圧差が15ボルトを下回ったときのみメインコンタクタを閉じた。これは実世界のプリチャージロジックを反映している。
決定的に、これは単なるシミュレーションの見せ物ではなかった。アプリケーションロジックとハードウェアドライバーが織り交ぜられた完全なモデルが組み立てられた後、チームはSimulinkのReal-Time Workshop（RTW）を使用して、Keil µVision（標準的なARM開発IDE）向けの完全な、コンパイル準備の整ったCプロジェクトを自動生成した。バックグラウンドで、MATLABはCOMオートメーションを介してSTM32CubeMXを呼び出し、生成されたコードが設定されたハードウェア抽象化層（HAL）と完全に同期し続けることを保証した。手動編集なし。コピー＆ペーストの不一致なし。ワンクリックで、一貫したコードベースが得られる。
そして、本当のテスト、つまりデプロイメントがやってきた。
研究者たちは半物理的なテストリグを構築した。機械式ポテンショメーターがアクセルペダルとブレーキペダルの代わりとなった。タクタイルプッシュボタンはキーポジション（OFF/ON/START）とギアセレクター（D/N/R）を模倣した。これらは実際のアナログおよびデジタル信号をSTM32ボードの物理ピンに供給した。ここではシミュレートされた入力はない。一方、LabVIEWベースのホストPCは、VCUからストリーミングされるUARTテレメトリを監視し、タイムスタンプ、状態フラグ、トルク要求、電圧読み取り値をリアルタイムで記録した。
結果は驚くべきものだった。VCUが新しい機能を実行したからではなく、既知の機能を最初の起動から完璧に、予測可能に実行したからだ。
一つのテストシーケンスでは、1.3秒で「KEY_ON」ボタンが押された。ミリ秒単位で、VCUはBMS起動信号をトリガーし、プリチャージリレーを閉じた（PreRelay = 1）。オペレーターが「コントローラー電圧」のポットをゆっくり回すと、システムはプリチャージモードで待機を続けた。シミュレートされた電圧が（固定の100Vバッテリーパックに対して）85Vに達した時点で、設計通り正確に、プリチャージリレーが開放され（PreRelay = 0）、メインリレーが閉じられた（MainRelay = 1）。低電圧電源投入完了。
その後、3.9秒で「KEY_START」が作動した。VCUはモーターコントローラー（MCU_Enable = 1）を起動し、故障がないことを確認し、DC/DCコンバーターを有効にした。システムは「レディ」モードに入った。ライト点灯、エラーなし、駆動系作動準備完了。すべての遷移は期待されるタイミングと論理的依存関係と一致した。手順の見落としはなく、競合状態もなかった。
さらに示唆に富んだのは動的な運転シミュレーションだった。1.2秒で、ギアセレクターがニュートラルからドライブに移動した。VCUは車速が8 km/h未満（前進進入のための安全ゲート）であることを確認し、シフトを許可した。その後、1.4秒で、アクセルペダルが30%まで押され、トルクがスムーズに上昇し、シミュレートされたダイナミクスモデルで前進運動が開始された。
真のストレステストは2.3秒に訪れた。まだ前進速度5 km/hで動いている状態でのドライブからリバースへの直接シフトだ。従来の知恵、そして多くの量産ECUは、これを安全でないとして拒否するだろう。しかし、チームは安全性を損なうことなく市街地の maneuverability（操縦性）を向上させるために、低速での双方向シフト許可（≤8 km/h）を明示的にエンコードしていた。そしてシステムはそれに従った。トルクの符号が反転し、減速が始まり、速度はゼロにまで低下し、後退運動が開始された。不具合も、切断もなかった。
そして、決定的な瞬間：5.0秒で、ブレーキペダルが押された。瞬間的に—同じ制御サイクル内で—アクセルペダルの位置に関わらず、トルク指令はゼロに落ちた。この「ブレーキ優先オーバーライド」は、世界的に義務付けられた絶対的な安全要件である。それが、激しい加速中でさえ即座に作動した事実は、ロジックだけでなく、自動生成されたコードのリアルタイム決定性をも検証した。後に、18.2秒で、別のブレーキ操作がフルスロットル入力を同じ信頼性でオーバーライドした。緊急介入のために不可欠な振る舞いである。
目立つのは、派手なAIや風変わりなハードウェアではない。それは規律である。組み込み自動車開発において最も回避可能な故障モード、すなわち人的な転記エラーを排除した点だ。CAN信号のスケーリング係数のタイプミス、ウォッチドッグタイマーの初期化忘れ、アルゴリズム更新とそのHAL依存関係の間のバージョンの不一致に起因する現場でのリコールはどれほどあっただろうか。
この研究は、設計によってこれらのリスクを回避する。Simulinkモデルが仕様であり、コードがそのモデル—手動介入なしに全体としてコンパイルされる—であるとき、概念からシリコンへの道筋は、監査可能、反復可能、認証可能となる。これは、ISO 26262の下で働く機能安全エンジニアにとっては歓迎すべきことだ。トレーサビリティは向上する。テストカバレッジはより意味のあるものになる。車両プラットフォーム間—例えば、都市型EVから軽商用バンへ—でのモデルの再利用は、何週間もかかる再統合作業なしに実現可能になる。
業界のベテランは、AUTOSARの階層化された標準化ソフトウェアアーキテクチャのビジョンとの類似点を指摘するだろう。しかし、小規模なOEMやスタートアップにとってAUTOSARの完全採用はコストが高く複雑なままであるのに対し、このSimulink + STM32-MAT/TARGETの道筋は、安全重視の機能には十分に厳格でありながら、迅速なプロトタイピングや学術研究にも十分にアクセス可能な、実用的な中間地点を提供する。
もちろん、論文はその範囲が概念実証（proof of concept）であることを認めている。故障信号はハードコードされ（BMS_Fault = 0, VCU_Fault = 0）、検証が簡素化されていた。実車は、数十の非同期故障フラグ、熱的出力低下曲線、絶縁監視、リンプホーム戦略—ここではまだモデル化されていない層—を扱わなければならない。また、リアルタイム性能は代表的なMCUで検証されたが、マルチコアプロセッサやタイムトリガーアーキテクチャ（ASIL-Dシステム向けなど）へのスケーリングは、RTOSスケジューラーやメモリ保護ユニットとのより深い統合を必要とするだろう。
著者自身も、次の論理的なステップとしてハードウェアインザループ（HIL）共同検証を指摘している。自動生成された組み込みコードの出力を、元のSimulinkオフラインシミュレーションの出力と—ロジックだけでなくタイミングの忠実度においても—比較することは、負荷下でのジッター、最悪実行時間（WCET）、割り込み待ち時間を定量化するだろう。そのデータは、生産展開前に不可欠である。
それでも、基盤は堅牢である。そしてそのタイミングは最高だ。
巨視的なトレンドを考えてみよう。EVスタートアップは残忍な資本効率の要求に直面している。レガシーOEMは、内燃機関の論理に浸った何千人ものエンジニアの再訓練に躍起になっている。規制機関は、ソフトウェアが定義する安全性に対する監視を強化している。この環境下では、厳密さを犠牲にすることなく開発サイクルを圧縮するツールは、単に便利なだけでなく、存続に関わるものなのである。
既に、主要なティア1サプライヤーが同様のワークフローのパイロット運用を開始しているという噂がある。いくつかはVCUを超えて—バッテリー管理、熱システム、さらにはステアバイワイヤコントローラーへ—パラダイムを拡張している。共通の糸？モデルを権威あるものに保つ。機械にコードを書かせる。
これは、超低遅延のモーター制御のための手動最適化アセンブリを置き換えるだろうか？考えにくい。性能の最先端では、職人芸レベルの組み込み技術には常に場所があるだろう。しかし、車両制御機能の大部分—状態管理、信号調停、モード遷移、診断シーケンス—にとって、このレベルの自動化は実行可能であるだけでなく、ベストプラクティスになりつつある。
南京の実験装置は質素に見えるかもしれない。ブレッドボード、いくつかのポテンショメーター、LabVIEWを実行するラップトップ。しかし、それが代表するものは遥かに大きい。インテリジェントな車両がどのように生まれるかについての静かな革命—コードとハードウェアの分断されたサイロではなく、統一された、自己無撞着なシステムとして、最初の半田付けが冷める前に検証されるのである。
電動化が加速する中、ボトルネックはもはやバッテリー化学やモータートポロジーではない。それはエンジニアリングのリソースである。このような方法は、統合の頭痛の種となる何週間もを節約するだけでなく、エンジニアが車両を真に差別化するもの—ドライビングフィール、エネルギー回生のニュアンス、適応型熱戦略、オーバーザエアアップデートの回復力—に集中するための認知的空間を解放する。体験であって、配管工事ではない。
そして、ブランドロイヤルティがシャシーダイナミクスと同じくらいソフトウェアの応答性に依存する業界において、その焦点の変化は決定的となるかもしれない。
最後に一言。論文のDOI—10.3969/j.issn.1674–8425(z).2023.05.002—は単なる引用脚注ではない。それは道標である。「コードは職人技」から「コードは継続的、検証済みの成果物」への移行におけるマーカーである。統合のずれとテスト負債に日々格闘する開発者にとって、ブックマークする価値がある。
なぜなら、車両制御の未来は、C言語で一行一行書かれるものではないだろうからだ。それは、自信を持って、端から端までモデリング、シミュレーション、生成されるだろう。そしてその未来は、このような仕事のおかげで、すでにテストコース上にあるのである。
Huan Shen, Fuliang Zhou, Jianguo Mao, Wei Chen, Zhiwei Yan, College of Energy and Power Engineering, Nanjing University of Aeronautics and Astronautics, Journal of Chongqing University of Technology (Natural Science), DOI: 10.3969/j.issn.1674–8425(z).2023.05.002