私たちについて
Hyperdrivesは、2021年にミュンヘンで設立されたディープテック・エンジニアリング企業です。当社は、中空導体冷却式モーターを中核とした高出力密度の電気駆動システムを開発しており、そのパッケージサイズは現在のシリーズモーターに比べて最大50％小型化されています。また、プロジェクト顧客向けにターンキー方式の駆動システムを供給するとともに、OEMやティア1サプライヤーと連携して産業化に向けた取り組みを進めています。 当社のソフトウェアチームは小規模ですが、ロードマップは広範にわたり、電力試験台での1時間1時間が極めて重要です。
Typhoon HIL を活用することで、テストベンチでの試験時間を確保するずっと前から、各自のデスクで毎日インバータソフトウェアの検証を行っています。
私たちの始まり
モーターインバータ用のソフトウェアを開発している人なら、誰もがこの状況をよく知っているでしょう。新しいビルドが完成すると、それが動作するかどうかを尋ねる間もなく、すぐに「いつテストベンチを使えるか」と尋ねてしまうものです。長い間、テストベンチの空き状況が、私たちの1週間のスケジュールをほぼ決定づけていました。しかも、テストベンチは数が限られているだけでなく、ソフトウェアのバグを発見する場所としては最もコストがかかる場所でもあります。 電流リファレンスの符号間違い、トルクステップ中のCANメッセージの処理ミス、あるいはトリップが遅すぎる保護閾値――こうしたミスが原因で、インバータのプロトタイプやモーターのサンプルを台無しにしてしまう可能性があります。通電状態で何か問題が発生してしまうと、その原因がソフトウェアにあるのかハードウェアにあるのかを特定するのに、数時間ではなく数日かかってしまいます。
試験台が整った後も、パワーステージ、モーター、保護回路、計測機器のセットアップには、最初の試験が始まるまでに午前中の半分は軽くかかってしまうことがよくありました。モーターのバリエーションが2種類あり、キャリブレーション、チューニング、デバッグのすべてに同じだけの試験台使用時間が必要だったため、別のアプローチが必要であることは明らかでした。
モーターをデスクの上に置く
そこで、少なくともシミュレーション上では、モーターを自分たちのデスクに移しました。現在、当社のインバータ制御ボードは低電圧信号を介してTyphoon社のHIL506に接続されており、HILは、かつて試験台が提供していたもの――モーター、パワーステージ、DCリンク――をリアルタイムでシミュレートしています。Typhoonでモーターモデルを構築し Schematic Editorでモーターモデルを構築し、HIL SCADAパネルを追加して、TyphoonTest IDEと Typhoon HIL Python APIを使用してテストを自動化しました。モーターモデルは飽和を含む非線形モデルであり、以前のテストベンチでの測定結果に基づいてパラメータ化されています。これにより、コントローラはHIL上で、後にテストベンチで実際に遭遇するのと同じモーターを認識できるようになります。
導入から1週間も経たないうちに、制御ボードは実際のモーターと同様に、シミュレーションされたモーターに対して正常に動作するようになりました。当初は実験として始まったものが、今では私たちの業務の当たり前の一部となっており、現在では新しいソフトウェアのビルドはすべて、テストベンチに送られるよりずっと前に、まずHILで検証されるようになっています。
テストベンチは、もはや私たちが作業を始める場所ではなくなりました。そこでは、確認を行う場所となったのです。
2つのモーター、独自開発のCAN、そしてすべてのビルドでのテスト
最初に気づいたことの一つは、Gen3とUltraという2つのモーター世代の切り替えがいかに簡単かということでした。どちらのモデルも同じインターフェースを採用しているため、モーターを交換するには、単に別のモデルを読み込むだけで済みます。作業には数分しかかからず、配線のやり直しも不要です。
CANも柔軟に対応できました。自動テストでは、Typhoonモデルが通信を処理します。自分たちで状況を確認したい場合は、独自のCANツールやインバータのGUIを接続し、HILにはモーターのみをシミュレートさせます。いずれの場合も、ソフトウェアが変更されるたびに、メッセージとそのタイミングを再確認することができます。
現在、ステートマシン回帰テストは自動的に実行され、終了時にレポートが生成されるようになっています。今後は、他のテスト領域も順次追加していく予定です。過電流、過熱、セーフ・トルク・オフなど、実際の試験台では再現が難しい故障も、モデル上では必要な時にいつでも意図的に発生させることができ、プロトタイプにリスクを負わせることもなく、毎回同じ挙動を示します。より詳細な調査を行う際には、直感的なSCADAパネルを活用しています。
AIは、テストの作成方法も変えました。仕様書とテスト対象領域に関する簡単なプロンプトを基に、AIがそれらをテスト計画と詳細なテストケースに分解してくれます。特に、手作業では見落としがちなエッジケース――範囲内の最後の値や範囲外の最初の値、両方向の回転、無効な状態リクエスト、CANメッセージの受信停止など――の検出に優れています。 仕様書に値が明記されていない場合、AIは推測するのではなく「未定」としてマークするため、エンジニアは後で架空の数値を考案するのではなく、そのギャップを埋めることができます。レビュー済みのテストケースをもとに、AIはPythonでTyphoonTest スクリプトを生成します。このスクリプトは、TyphoonTest IDEからTyphoon HIL APIを経由してHIL上で実行され、その結果は他の回帰テストの結果と同じレポートに追加されます。エンジニアは、その過程のすべてのステップをレビューし、承認します。
箱を開ける、でも箱は開けない
デバッグ機能は、最も大きな改善点の一つであることが判明しました。テストベンチ上では、当社の制御ボードはインバータ筐体内部、ベンチの保護装置の後ろに設置されているため、（写真にあるラウターバッハのような）デバッガを接続するには、カバーを開け、安全装置を避けて作業する必要がありました。
HILでは、ボードは机の上に開いた状態で置かれます。ラウターバッハのケーブルを接続し、シミュレートされたモーターに対してソフトウェアを実行し、テストの実行中にレジスタや変数をリアルタイムで読み取ります。これにより、詳細なデバッグは、事前に計画を立てる必要のある作業ではなく、必要なときにいつでも行えるようになりました。
テストベンチへの搬入完了
以前は、キャリブレーションに実験台の作業時間を多く費やしていました。現在では、現行のコントローラのラムダ帯域幅の調整を行い、HIL上で両方のモーターのパラメータを設定しているため、新しいソフトウェアがリリースされるたびに、すでに調整済みの状態で実験台に届くようになっています。目標帯域幅を設定し、シミュレーション上のモーターの応答を確認した上で、パラメータを設定します。キャリブレーションパラメータの構造全体についても、同様の方法で構築・検証を行いました。
そのため、実際に試験台で作業を行う段階になると、下準備の大部分はすでに完了しているため、一からやり直すのではなく、その時間を実際のモーターでの結果の確認に充てることができます。また、試験台で何らかの対応が必要になった場合でも、制御ソフトウェアが原因である可能性はほぼ排除できるため、試験台の本来の目的である熱的挙動、NVHへの影響、および機械的特性に集中することができます。
私たちにとって何が変わったのか
私たちにとって最大の変化は、作業が行われる場所です。テスト、デバッグ、チューニング、およびキャリブレーションは、実験台からデスクへと大きく移行し、ソフトウェアチームはもはやハードウェアを待たずに作業を進めることができるようになりました。ソフトウェアの問題は、すべての信号が可視化された状態でデスク上で明らかになり、数日ではなく数時間で修正されるようになりました。
次は？
AIが作成したテストケースは、すでに私たちの日常的なワークフローの一部となっています。次のステップは、エージェント主導の開発フローです。私たちは「Typhoon HIL 」アプリケーション用のMCPサーバーを構築し、基本的な呼び出しを用いてテストを行いました。完全なエンドツーエンドのワークフローはまだ開発中ですが、その基盤は整っており、今後さらに発展させていくことを楽しみにしています。
数分でモーターを交換でき、オープンボード上でデバッグを行い、試験台に移す前に調整できるようになったことで、私たちのチームの働き方は大きく変わりました。
ベンジャミン・ヘングストラー
共同創業者兼最高ソフトウェア責任者
Hyperdrives
以前はテストベンチの設定に費やしていた時間が、今ではソフトウェアの改善に充てられています。
ウタラ・キールタン・ラマムーティ
組み込みソフトウェア開発者
Hyperdrives
モーターを組み立てられるほどよく理解していれば、それをモデル化できるほど理解していることになります。その段階になれば、コントローラは両者の違いを見分けることができなくなり、その瞬間こそが、すべてをテストできる時なのです。
アンドレア・ロイ
テクニカルセールスリードeモビリティ DACH
Typhoon HIL
