(57)【要約】【課題】車両モデルを構成する複数のユニットモデルを整合させる。【解決手段】エンジンモデル１３０のトルク出力がサスペンションモデル１３２に入力されるとき、エンジンモデル１３０のトルク出力として試験値を設定する。試験値を設定したときのサスペンションモデル１３２の出力、たとえば、ハンドル負荷が所定の整合条件を満たさないとき、エンジンモデル１３０からのトルク出力に所定の変換処理を施してからサスペンションモデル１３２に入力させる。具体的には、試験値に基づく想定範囲からサスペンションモデル１３２が出力するハンドル負荷が外れるとき、トルク出力の単位系を変換する補正ソフトウェアを追加する。【選択図】図３
2016021172.tif 000002
【特許請求の範囲】
【請求項１】
車両を構成する複数のユニットの動作をそれぞれエミュレートする複数のモデルに制御条件を設定する条件設定部と、
第１のモデルの第１の出力が第２のモデルに入力されるとき、前記第１の出力として試験値を設定する試験値設定部と、
前記試験値を設定したときの前記第２のモデルの第２の出力が所定の整合条件を満たさないとき、前記第１の出力に所定の変換処理を施してから前記第２のモデルに入力させる変換設定部と、を備えることを特徴とする車両シミュレーションシステム。
【請求項２】
前記変換設定部は、前記試験値に基づく想定範囲から前記第２の出力が外れるとき、前記第１の出力の単位系を変換する補正ソフトウェアを追加することを特徴とする請求項１に記載の車両シミュレーションシステム。
【請求項３】
前記変換設定部は、前記第１の出力の種別に対応する複数の変換係数の中から前記整合条件を満たす変換係数を選択し、前記第１の出力を前記選択した変換係数により変換することを特徴とする請求項１に記載の車両シミュレーションシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両のシミュレーションに関し、特に、車両を構成する複数のユニットをエミュレートするモデルの連結に関する。
【背景技術】
【０００２】
自動車などの車両を制御するシステムの複雑化にともない、実機試作の前に車両全体をソフトウェアでモデリングして、シミュレーション・テストするようになってきている（特許文献１参照）。車両シミュレーションでは、まず、車両を構成するユニットをソフトウェアでエミュレートしたモデルを用意する。たとえば、エンジンのモデルは、エンジンにおける点火やそれにともなうシャフトの動き、などを忠実に再現するソフトウェアである。エンジンモデルの出力情報の一部はサスペンションモデルの入力情報となる。このように複数のモデルを組み合わせて、車両全体をモデリングする。
【０００３】
車両モデルに対して、路面条件などの環境情報のほか、急発進や急停止などのさまざまなテスト項目を設定し、車両モデルを動作させ、各ユニットがどのように動きどのようなな負荷がかかるかを検証する。
以下、車両を構成するユニットのモデルを「ユニットモデル」とよび、車両全体としてのモデルのことを「車両モデル」とよぶことにする。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−２３７５５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ユニットモデルは、さまざまなサプライヤから提供される場合があるため、ユニットモデルの単位系は統一されていない。たとえば、エンジンモデルがＮ（ニュートン）単位でトルクを出力し、これがサスペンションモデルに伝わるとする。しかし、サスペンションモデルがトルクをｋＮ単位で解釈する場合、１Ｎのトルクを１ｋＮと誤解してしまうため車両モデル全体としての整合が取れなくなってしまう。
【０００６】
このため、複数のユニットモデルを組み合わせて車両モデルを作る設計者は、ユニットモデルのインタフェースをチェックし、単位系が不整合となっているときには、単位系を変換するための補正ソフトウェアを適宜追加する。上記の例では、エンジンモデルとサスペンションモデルの間に、エンジンモデルが出力するトルクを１／１０００倍してからサスペンションモデルに入力させる補正ソフトウェアが追加されなければならない。
【０００７】
しかし、多種多様なユニットモデルの複雑なインターフェースを確認しながら、整合性を確認していくのは作業負担が大きくそれゆえにヒューマンエラーのリスクがつきまとう。エンジンモデルから出力されるのはトルクだけでなく回転数などさまな情報があるため整合性の確認・補正作業の負担は非常に大きい。
【０００８】
しかも、車両モデルのシミュレーションは、一般的には、数時間から数日間かけて行われるほど大規模なものである。このため、シミュレーション中に不整合に気づいた場合、改めて補正ソフトウェアを追加してシミュレーションをやり直すのは時間ロスが大きい。
【０００９】
本発明は、こうした状況に鑑みてなされたものであり、その主たる目的は、車両モデルを構成する複数のユニットモデルを整合させる作業の負担を軽減することである。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明のある態様の車両シミュレーションシステムは、車両を構成する複数のユニットの動作をそれぞれエミュレートする複数のモデルに制御条件を設定する条件設定部と、第１のモデルの第１の出力が第２のモデルに入力されるとき、前記第１の出力として試験値を設定する試験値設定部と、前記試験値を設定したときの前記第２のモデルの第２の出力が所定の整合条件を満たさないとき、前記第１の出力に所定の変換処理を施してから前記第２のモデルに入力させる変換設定部と、を備える。
【００１１】
まず、第１のモデルの出力、すなわち、第２のモデルの入力に試験値を設定したときの第２のモデルの出力を確認する。そして、第１のモデルと第２のモデルの単位系や座標系などに不整合が生じていないかを自動的にチェックし、必要に応じて第１のモデルの出力系を第２のモデルの入力系に適合するように補正するため、ユニットモデルを複雑に組み合わせて車両モデルを構築するときの設計者の負担が軽減される。
【００１２】
変換設定部は、試験値に基づく想定範囲から第２の出力が外れるとき、第１の出力の単位系を変換する補正ソフトウェアを追加してもよい。試験値に応じて、第２のモデルからの出力としておおよその範囲を想定できるため、第２の出力から簡易に整合性をチェックしやすくなる。
【００１３】
変換設定部は、第１の出力の種別に対応する複数の変換係数の中から整合条件を満たす変換係数を選択し、第１の出力を選択した変換係数により変換してもよい。
【００１４】
第１の出力の種別が「力」のときには、力の単位としてｋｇ重、Ｎ、ｋＮなどが考えられる。この場合、変換係数は、「×１０００」や「×９．８」などが想定される。一方、第１の出力の種別が「角速度」のときには、単位としては「rad/s」や「degree/msec」などが考えられるため、角速度の変換係数と力の変換係数は一致しない。このように、第１の出力の種別に応じて変換係数候補をリスト化しておくことにより、妥当な変換係数を決定しやすくなる。
【発明の効果】
【００１５】
本発明によれば、車両モデルを構成する複数のユニットモデルを整合させるための作業負担を軽減しやすくなる。
【図面の簡単な説明】
【００１６】
【図１】車両シミュレーションシステムのハードウェア構成図である。
【図２】制御端末と車両シミュレータの機能ブロック図である。
【図３】ユニットモデルの連携例を示す模式図である。
【図４】補正ソフトによる整合処理過程を示すフローチャートである。
【発明を実施するための形態】
【００１７】
図１は、車両シミュレーションシステム１００のハードウェア構成図である。
車両シミュレーションシステム１００は、互いに通信線で接続された車両シミュレータ１０２と制御端末１０４を含む。車両シミュレータ１０２は、車両モデルのシミュレーション・テストを実行する。制御端末１０４は、車両シミュレータ１０２の車両モデルに各種設定を行うとともに、シミュレーションの状況を監視する。本実施形態においては、車両シミュレータ１０２と制御端末１０４は別々であるとして説明するが、車両シミュレータ１０２が制御端末１０４の機能の全部または一部を取り込んでもよい。
【００１８】
図２は、制御端末１０４と車両シミュレータ１０２の機能ブロック図である。
制御端末１０４と車両シミュレータ１０２の各構成要素は、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされた本図の構成要素を実現するプログラム、そのプログラムを格納するハードディスクなどの記憶ユニット、ネットワーク接続用インタフェースを中心にハードウェアとソフトウェアの任意の組み合わせによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。以下説明する各図は、ハードウェア単位の構成ではなく、機能単位のブロックを示している。
【００１９】
制御端末１０４は、設定部１０６と監視部１１２を含む。設定部１０６は、車両モデル１２６や環境モデル１３６（後述）に対して各種設定を行う。設定部１０６は、制御条件を設定する条件設定部１０８と試験値を設定する試験値設定部１１０を含む。制御条件と試験値についても後述する。監視部１１２は、車両モデル１２６のシミュレーション結果を監視し、制御端末１０４の画面に表示させる。
【００２０】
車両シミュレータ１０２は、通信部１１４、補正部１１６およびシミュレーション部１２２を含む。通信部１１４は、制御端末１０４との通信処理を担当し、制御端末１０４と補正部１１６、シミュレーション部１２２のインタフェースとして機能する。
【００２１】
シミュレーション部１２２は、車両モデル１２６のシミュレーションを実行する。補正部１１６は、複数のユニットモデルを組み合わせて車両モデル１２６を構築するときにユニットモデルの整合させる補正処理を行う。
【００２２】
シミュレーション部１２２は、シミュレーションを統括的に制御する実行制御部１２４、車両モデル１２６および環境モデル１３６を含む。環境モデル１３６は、路面状況、風況、気温、天候などシミュレーションにおいて想定される外的環境をエミュレートするモデルである。車両モデル１２６は、車両の各ユニットをエミュレートする複数のユニットモデルを含む。具体的には、車両モデル１２６は車体モデル１２８、エンジンモデル１３０、サスペンションモデル１３２およびドライバーモデル１３４を含むが、これ以外にもさまざまなユニットモデルが追加されてもよい。
【００２３】
車体モデル１２８は、車体やシャーシなどにかかる負荷をエミュレートするユニットモデルである。エンジンモデル１３０は、エンジンをエミュレートしたユニットモデルである。サスペンションモデル１３２は、タイヤやサスペンションをエミュレートしたユニットモデルである。ドライバーモデル１３４は、ドライバーの操作やドライバーにかかる負荷などをエミュレートしたモデルである。
【００２４】
ユニットモデルは、ユニットの種類だけでなくエミュレートの精度によっても多数のバリエーションがある。たとえば、車体モデル１２８は、車体を単純な「箱」としてエミュレートするものもあれば、車軸のねじれ現象までエミュレートするものもある。あるいは、車体を一種の弾性体としてとらえ、車体のわずかな変形までもエミュレートできるユニットモデルもある。どのような車体モデル１２８を選択するかは、シミュレーションに求められる速度や精度等に応じて決定される。他のユニットモデルについても同様である。
【００２５】
ユーザは、条件設定部１０８を介して、どのようなユニットモデルを選ぶか、どのようなテストを行うか、環境モデル１３６としてどのような環境を想定するか、などの各種の条件設定を行う。このような条件のことを「制御条件」とよぶ。また、シミュレーションの実行周波数も制御条件の一種として設定される。たとえば、エンジンモデル１３０において０．１（マイクロ秒）ごとにシャフトの動きを計算してもよいし、１（マイクロ秒）ごとに計算してもよい。実行周波数が大きいときには各ユニットモデルの細かな動きを監視できる代わりにシミュレーション全体の時間がかかる。実行周波数を小さくするとシミュレーション時間は短くなるがユニットモデルの監視精度はラフになる。
【００２６】
ドライバーモデル１３４は、状況に応じてドライバーがどのような動作をするかという設定がなされている。あるいは、状況に応じてどのような動作をするかをドライバーに判断させる人工知能としてドライバーモデル１３４を構築してもよい。
【００２７】
また、ドライバーや車体、タイヤなどのオブジェクトの各部にかかる負荷を有限要素法により計算してもよい。たとえば、どのような状況でどのような運転をするとドライバーの内臓にどのような負荷がかかるかをシミュレーションすることにより、いわゆる「乗り心地」を車両シミュレーションで判断できる。
【００２８】
各種の制御条件を設定したあと、実行制御部１２４は車両モデル１２６のシミュレーション実行を開始する。各ユニットモデルや環境モデル１３６は互いに情報を交換しながら、それぞれの動作を行う。
【００２９】
補正部１１６は、変換設定部１２０を含む。ユーザは、ユニットモデルのインタフェースを設定する。たとえば、車体モデル１２８の出力１がドライバーモデル１３４に入力され場合、「車体モデル１２８からドライバーモデル１３４に出力１が入力される」という情報が特定される。変換設定部１２０は、各インタフェースについて整合が取れているかをチェックし、不整合の場合にはこれを補正する。補正方法の詳細は次の図３に関連して詳述する。
【００３０】
図３は、ユニットモデルの連携例を示す模式図である。
ここでは、エンジンモデル１３０、サスペンションモデル１３２、環境モデル１３６およびドライバーモデル１３４の連携例を示している。エンジンモデル１３０は、さまざまな情報を出力するがそのうちの一つはトルクでありこれがサスペンションモデル１３２への入力となる（Ｓ１）。サスペンションモデル１３２には、環境モデル１３６から路面情報などの環境情報も入力される（Ｓ２）。サスペンションモデル１３２は、これらの入力情報に基づいてサスペンションなどにかかる負荷を独自のアルゴリズムにて計算し、ドライバーモデル１３４にハンドル負荷（ステアリングの手応え）を伝える（Ｓ３）。ドライバーモデル１３４は、ハンドル負荷という入力情報に基づいてあらかじめ決められた操作を行い、この操作内容がエンジンモデル１３０に伝えられる（Ｓ４）。
【００３１】
ここで、エンジンモデル１３０はトルクをＮ単位で伝え、サスペンションモデル１３２はｋＮ単位でトルクを受け取ることを想定しているとする。この場合、サスペンションモデル１３２は、エンジンモデル１３０の出力値を１０００倍に解釈してしまうため、必然的に、サスペンションモデル１３２はドライバーモデル１３４に対して非常に大きなハンドル負荷を伝えてしまうことになる。
【００３２】
そこで、シミュレーションを実行開始する前に、試験値設定部１１０は、トルクに試験値を設定する。たとえば、試験値としてＡ１（Ｎ）を設定したとする。トルクがＡ１（Ｎ）の場合、サスペンションモデル１３２から出力されるハンドル負荷として想定される範囲はＢ１〜Ｂ２であるとする。Ｂ１はＡ１のトルクに対して想定可能な最小ハンドル負荷であり、Ｂ２は同じく想定可能な最大ハンドル負荷である。もし、エンジンモデル１３０とサスペンションモデル１３２の単位系が整合していれば、サスペンションモデル１３２から出力されるハンドル負荷はＢ１〜Ｂ２の範囲に収まる。試験値Ａ１は、ハンドル負荷の範囲Ｂ１〜Ｂ２を確定しやすいシンプルな値であることが望ましい。
【００３３】
もし、二つのユニットモデルの単位系が整合していない場合には、ハンドル負荷はこの範囲から外れてしまう。たとえば、サスペンションモデル１３２が入力されるトルクをｋＮ単位で解釈するユニットモデルである場合、サスペンションモデル１３２はＡ１（Ｎ）をＡ１（ｋＮ）と解釈してしまうため、Ｂ２よりもはるかに大きなハンドル負荷を出力する。変換設定部１２０は、ハンドル負荷がＢ１〜Ｂ２の想定範囲から外れたときには、エンジンモデル１３０とサスペンションモデル１３２の間に補正ソフトウェアを追加する。補正ソフトウェアは、エンジンモデル１３０のトルクに所定の変換係数を乗じてサスペンションモデル１３２に入力させるためのソフトウェアである。複数の変換係数に対応して複数の補正ソフトウェアを用意してもよいし、１つの補正ソフトウェアが複数の変換係数からいずれかを選択するとしてもよい。
【００３４】
トルクの種別は「力」であるため、ＮやｋＮ以外にもｋｇ重や、ｇ重などさまざまなものが想定される。この場合、補正ソフトウェアの変換係数は、×１０００（ｋＮ→Ｎ）、×１／１０００（Ｎ→ｋＮ）、×９．８（ｋｇ重→Ｎ）などが候補になる。
【００３５】
補正ソフトウェアを追加後、試験値Ａ１を再度設定し、サスペンションモデル１３２から出力されるハンドル負荷をチェックする。こうして、変換係数を変更しながら、エンジンモデル１３０の出力の単位系とサスペンションモデル１３２の入力の単位系を整合させる。
【００３６】
単位系としては力のほかに、加速度や速度、角速度などさまざまな物理量が考えられる。エンジンモデル１３０のような前段のユニットモデルの出力が力以外のときには変換係数の候補も異なる。たとえば、角速度の単位は、rad/msecやrad/msec、degree/secなどが考えられるため、補正ソフトウェアの変換係数は×１０００（rad/msec→rad/sec）、×５７（rad/msec→degree/msec）などが候補になる。
【００３７】
試験値とそれにともなう想定範囲は、制御端末１０４からユーザが設定してもよいし、試験値に応じた想定範囲をあらかじめ定義しておいてもよい。更に、単位系だけでなく座標系の整合についてもチェックする必要がある。エンジンモデル１３０が想定するｘｙｚ座標系とサスペンションモデル１３２が想定するｘｙｚ座標系が一致していないときには、補正ソフトウェアにより座標系を整合させる必要がある。たとえば、サスペンションモデル１３２は路面垂直方向をｚ方向として計算しているが、サスペンションモデル１３２から力を伝えられる車体モデル１２８は垂直方向をｘ方向としているかもしれない。この場合には、サスペンションモデル１３２の出力の単位系をｚ→ｘとなるように変換する必要がある。
【００３８】
更に、あるユニットモデルが出力するデータ１とデータ２が同じ単位系とは限らない。データ１は１０，０００〜１０，０００Ｎ程度となり、データ２は０．１〜０．５Ｎ程度となる出力である場合、データ１はｋＮ単位で計算する方がメモリを有効利用できる。したがって、ユニットモデル１からユニットモデル２にデータ１とデータ２が出力されるときには、データ１とデータ２のそれぞれについて整合性をチェックし、必要であればデータ１を変換する補正ソフトウェア（変換係数）とデータ２を変換する補正ソフトウェア（変換係数）を別々に追加する。
【００３９】
制御端末１０４は、車両モデル１２６の各ユニットモデルの配置を図３に示すように画面表示する。また、どのような補正ソフトウェアがどこに挿入されているかについても画面表示されてもよい。
【００４０】
図４は、補正ソフトによる整合処理過程を示すフローチャートである。
ユニットモデルを連結するときに、図４の整合処理が実行される。まず、ユーザは連結部（ユニットモデルのインタフェース）を指定する（Ｓ１０）。図３でいえば、「エンジンモデル１３０（第１のモデル）、トルク（第１の出力）、サスペンションモデル１３２（第２のモデル）、ハンドル負荷（第２の出力）」という連結関係が指定される。次に、試験値設定部１１０が所定の試験値を設定する（Ｓ１２）。変換設定部１２０は、このとき後段のユニットモデルの出力値を取得し（Ｓ１４）、この出力値が想定範囲内であれば整合しているとして（Ｓ１６のＹ）、整合処理は終了する。整合していないときには（Ｓ１６のＮ）、変換設定部１２０は補正ソフトウェアを設定し（Ｓ１８）、再度試験値を設定して検証を行う。整合がとれるまで変換係数をさまざまに変更する。
【００４１】
以上、実施形態に基づいて車両シミュレーションシステム１００について説明した。車両シミュレーションシステム１００によれば、多種多様なユニットモデルを組み合わせて車両モデルを構築するとき、各ユニットモデルの単位系や座標系などの整合性を「試験値」によりチェックできる。車両モデル全体を動かさなくても、たとえば、エンジンモデル１３０とサスペンションモデル１３２のような前後段のユニットモデルの入出力を試験値に基づいてチェックすることにより、２つのユニットモデルの整合性がとれているかをチェックできる。また、さまざまな変換係数に対応する補正ソフトウェアを挿入しながら、あるいは、単一の補正ソフトウェアの変換係数を変えながら自動的に整合が取れるように調整するため、設計者の作業負担を軽減できる。
【００４２】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００４３】
車両モデルを構成するユニットのうち、一部についてはユニットモデルではなく実機を用いてもよい。たとえば、エンジンだけは実機を使用し、エンジンへの入出力に関わるユニットについてはユニットモデルを使うことにより、ハードウェアとソフトウェアを混在させたシミュレーションも可能である。
【００４４】
補正部１１６に検索部を設け、検索部が整合確認をすべきインタフェースを自動的にリストアップしてもよい。
【符号の説明】
【００４５】
１００  車両シミュレーションシステム、  １０２  車両シミュレータ、  １０４  制御端末、  １０６  設定部、  １０８  条件設定部、  １１０  試験値設定部、  １１２  監視部、  １１４  通信部、  １１６  補正部、  １２０  変換設定部、  １２２  シミュレーション部、  １２４  実行制御部、  １２６  車両モデル、  １２８  車体モデル、  １３０  エンジンモデル、  １３２  サスペンションモデル、  １３４  ドライバーモデル、  １３６  環境モデル。
【図１】
2016021172.tif 000003
【図２】
2016021172.tif 000004
【図３】
2016021172.tif 000005
【図４】
2016021172.tif 000006