(58)【調査した分野】(Int.Cl.,DB名)
コンピュータに、制御システムの性能を検証するためのソースコードを生成するための方法を実行させるためのプログラムであって、前記プログラムは前記コンピュータに、
制御システムのモデルから、マルチコアプロセッサにおいて実行されるプログラムのシミュレーションの対象となるコード生成範囲の選択を受け付けるステップと、
前記コード生成範囲に含まれる複数の処理のうち、並列処理の対象となる複数の並列実行単位の指定を受け付けるステップと、
各前記並列実行単位と当該マルチコアプロセッサに含まれる各コアとの関連付けを行なうステップと、
前記関連付けが行なわれた各前記並列実行単位の実行順序とコア間同期とを指定するステップと、
各前記並列実行単位と前記実行順序とに基づいて、前記マルチコアプロセッサによる実行の対象となるソースコードを生成するステップと、
前記生成されたソースコードをマルチコアプロセッサにおいて実行し、モデルシミュレータにおいて実行するプラントモデルと連携シミュレーションを行うために通信するステップと、
前記連携シミュレーションにおいて、マルチコアプロセッサにおいて実行されるプログラムの実行時間を計測するステップとを実行させる、プログラム。
前記指定するステップは、前記複数の処理のうち依存関係にある2つ以上の処理を並列処理の対象から除外するステップを含む、請求項12または13に記載のプログラム。
【発明を実施するための形態】
【0020】
以下、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。
【0021】
図1を参照して、システム設計の概要について説明する。
図1は、システム設計の流れを表わす図である。
【0022】
フェーズ100において、システム設計が行なわれる。システム設計は、モデリング、モデルシミュレーション、自動コード生成(ACG:Auto Code Generation)などを含む。フェーズ100では、たとえば、MILシミュレーションあるいはPILシミュレーションが行なわれる。MILシミュレーションでは、制御のモデリングのため、制御対象およびコントローラのシミュレーションは、PC上で作動するモデルシミュレータ(たとえば、MATLAB)において実行される。この場合、詳細度や精度が重視され、シミュレーション自体は高速で実行される。しかしながら、プラント及びコントローラの制御サイクルの実行時間はシミュレーションされない。SILシミュレーションでは、モデルから生成されたコードベースで制御が成立するか否かが確認される。たとえば、コントローラモデルから生成されたコードは、PCで実行され、上記モデルシミュレータとの連携の下でシミュレーションが実行される。このSILシミュレーションでは、ソフトウェアとしての動作あるいは処理の規模が確認される。
【0023】
フェーズ110において、システム詳細設計/開発が行なわれる。たとえば、周辺シミュレーション、高精度シミュレーション、コーディング/デバッグ、単体テストなどが行なわれる。フェーズ110では、PILシミュレーション環境におけるシミュレーションが行なわれる。たとえば、コントローラモデルから生成されたコードがマイコンにおいて実行され、モデルシミュレータとの連携シミュレーションが実行される。このシミュレーション自体の速度は遅いが、マイコンの処理量が把握され得る。
【0024】
フェーズ120において、システム検証とシステムシミュレーションとが行なわれる。システム検証は、たとえば、実機テストとパラメータチューニングなどを含み得る。
【0025】
図2を参照して、本実施の形態に係る性能評価システムの制御構造について説明する。
図2は、システム設計が行なわれる処理の流れを表わすフローチャートである。ある局面において、性能評価システムは、性能評価装置として作動するコンピュータと、当該性能評価装置から作成されるソースコードを実行するマルチコアプロセッサとを備える。
【0026】
ステップS210にて、制御モデルが生成される(モデリング)。画面211に示されるように、PEが割り当てられる前のブロック線図がモデルとして表示される。
【0027】
ステップS220にて、シミュレーションが行なわれる。たとえば、MILS機能検証が行なわれる。
【0028】
ステップS230にて、PE割当ブロックが挿入される。画面212に示されるように、ブロックと、当該ブロックに割り当てられたPEとが、ブロック線図に表示される。
【0029】
ステップS240にて、マルチコアコードが生成される。
ステップS250にて、マルチコア連携シミュレーションが実行される。たとえば、コア割当プランニングが行なわれる。より具体的には、SILS機能検証、SILS性能検証、PILS機能検証、PILS性能検証などが行なわれる。
【0030】
ステップS260にて、制御周期時間で演算できているか否かが判断される。制御周期時間内で演算ができている場合には(ステップS260にてYES)、処理を終了する。そうでない場合には(ステップS260にてNO)、処理はステップS210に戻されるか、ステップ230に戻され、異なる割当てが行われる。
【0031】
[システムモデルの概要]
図3を参照して、本実施の形態に係るシステムモデル300について説明する。
図3は、システムモデル300の概要を表す図である。
【0032】
システムモデル300は、センサ310と、コントローラモデル320と、アクチュエータ330とを備える。コントローラモデル320は、第1ブロック321と、第2ブロック322と、第nブロック323とを含む。第1ブロック321と第2ブロック322とは、それぞれPE324に関連付けられている。第nブロック323は、PE325に関連付けられている。センサ310の出力は、コントローラモデル320に入力される。コントローラモデル320の出力は、アクチュエータ330に入力される。アクチュエータ330の出力は、センサ310にフィードバックされる。
【0033】
図3では、センサ310とアクチュエータ330とが制御対象であり、プラントモデルとしてPC上のモデルシミュレータでシミュレーションされる。コントローラモデル320は、制御設計初期の機能モデリング工程では、PC上のモデルシミュレータでシミュレーションされる。コントローラモデル320は、MBD開発環境で提供されるコーダと呼ばれるツールによって、モデルと同等の振る舞いのソースプログラムに変換することができる。当該ソースプログラムは、SILシミュレーションの検証に使用できる。さらに、コントローラモデル320は、マイコン向けのソースプログラムにも変換することができ、PILシミュレーションの検証に使用することができる。
【0034】
本実施の形態において、制御周期は、センサ310への入力からアクチュエータ330に対して制御値が出力されるまでの期間をいう。この場合、コントローラモデル320に対するコードは、PE324およびPE325にそれぞれ与えられる。たとえば、PE324は、コントローラモデル320に入力されたコードのうちから第1ブロック321および第2ブロック322を検知すると、これらのブロックに含まれる命令を実行する。その他のブロックを検知しても、PE324は、自身に関連付けられないことを確認すると、何も処理を実行しない。
【0035】
同様に、PE325は、第1ブロック321および第2ブロック322を検知しても、自身に関連付けられていないブロックであることを確認すると、これらのブロックに含まれる命令を実行しない。その後、第nブロック323を検出すると、PE325は、第nブロック323に含まれる命令を実行する。
【0036】
通信340,343は、プラントマイコン間通信に相当する。通信341,342は、マイコン内交換通信に相当する。
【0037】
図4を参照して、本実施の形態に係る装置の構成について説明する。
図4は、当該装置400のハードウェア構成を表わすブロック図である。装置400は、コンピュータ410、デバッグエミュレータ420、およびマイコン評価ボード430から構成される。マイコン評価ボード430は、マルチコアプロセッサ10と、通信IF(Interface)17とを含む。
【0038】
デバッグエミュレータ420は、コンピュータ410に接続されて、マイコン評価ボード430に搭載されたマルチコアプロセッサと通信し、マイコンの実行を制御して、実行結果を取得するための装置である。デバッグエミュレータ420は、マイコンを用いた制御システム開発では一般的に使用されている。したがって、詳細な説明は繰り返さない。
【0039】
コンピュータ410は、主たる構成要素として、プログラムを実行するCPU1と、コンピュータ410のユーザによる指示の入力を受けるマウス2およびキーボード3と、CPU1によるプログラムの実行により生成されたデータ、又はマウス2若しくはキーボード3を介して入力されたデータを揮発的に格納するRAM(Random Access Memory)4と、データを不揮発的に格納するハードディスク5と、光ディスク駆動装置6と、通信IF(Interface)7と、モニタ8とを備える。各構成要素は、相互にバスによって接続されている。光ディスク駆動装置6には、CD−ROM9その他の光ディスクが装着される。通信IF7は、USB(Universal Serial Bus)インターフェイス、有線LAN(Local Area Network)、無線LAN、Bluetooth(登録商標)インターフェイス等を含むが、これらに限られない。
【0040】
コンピュータ410における処理は、各ハードウェアおよびCPU1により実行されるソフトウェアによって実現される。このようなソフトウェアは、ハードディスク5に予め格納されている場合がある。また、ソフトウェアは、CD−ROM9その他のコンピュータ読み取り可能な不揮発性のデータ記録媒体に格納されて、プログラム製品として流通している場合もある。あるいは、当該ソフトウェアは、インターネットその他のネットワークに接続されている情報提供事業者によってダウンロード可能なプログラム製品として提供される場合もある。このようなソフトウェアは、光ディスク駆動装置6その他のデータ読取装置によってデータ記録媒体から読み取られて、あるいは、通信IF7を介してダウンロードされた後、ハードディスク5に一旦格納される。そのソフトウェアは、CPU1によってハードディスク5から読み出され、実行可能なプログラムの形式でRAM4に格納される。CPU1は、そのプログラムを実行する。
【0041】
図4に示されるコンピュータ410を構成する各構成要素は、一般的なものである。したがって、本実施の形態に係る最も本質的な部分は、コンピュータ410に格納されたプログラムであるともいえる。コンピュータ410の各ハードウェアの動作は周知であるので、詳細な説明は繰り返さない。
【0042】
なお、データ記録媒体としては、CD−ROM、FD(Flexible Disk)、ハードディスクに限られず、磁気テープ、カセットテープ、光ディスク(MO(Magnetic Optical Disc)/MD(Mini Disc)/DVD(Digital Versatile Disc))、IC(Integrated Circuit)カード(メモリカードを含む)、光カード、マスクROM、EPROM(Electronically Programmable Read-Only Memory)、EEPROM(Electronically Erasable Programmable Read-Only Memory)、フラッシュROMなどの半導体メモリ等の固定的にプログラムを担持する不揮発性のデータ記録媒体でもよい。
【0043】
ここでいうプログラムとは、CPUにより直接実行可能なプログラムだけでなく、ソースプログラム形式のプログラム、圧縮処理されたプログラム、暗号化されたプログラム等を含み得る。
【0044】
図5を参照して、本実施の形態に係る性能検証装置500の構成についてさらに説明する。
図5は、性能検証装置500によって実現される機能の構成を表わすブロック図である。性能検証装置500は、たとえば、コンピュータ400によって実現され得る。
【0045】
性能検証装置500は、入力部510と、操作部520と、記憶部530と、選択部540と、並列実行単位指定部542と、割当部544と、実行順序指定部546と、生成部548と、シミュレーション実行部550と、表示部560とを備える。
【0046】
入力部510は、性能検証装置500に対するコードその他のデータの入力を受け付ける。入力部510は、たとえば、Ethernet(登録商標)、有線または無線LAN(Local Area Network)その他の通信インターフェイスによって実現される。
【0047】
操作部520は、性能検証装置500の使用者による操作を受け付ける。操作部520は、たとえば、マウス、キーボードその他の入力デバイスによって実現される。
【0048】
記憶部530は、性能検証装置500に対して与えられたデータまたは性能検証装置500において生成されたデータなどを格納する。記憶部530は、たとえば不揮発性の記憶装置(ハードディスク、フラッシュメモリなど)、または、RAMその他の揮発性の記憶装置によって実現される。
【0049】
選択部540は、表示部560に表示される制御システムのモデルから、マルチコアプロセッサにおいて実行されるプログラムのシミュレーションの対象となるコード生成範囲の選択を受け付ける。ある局面において、選択部540は、たとえば操作部520に対して与えられた使用者の命令に応答して、コード生成範囲を選択する。
【0050】
並列実行単位指定部542は、操作部520に対する操作に応答して、選択部540において選択されたコード生成範囲に含まれる複数の処理のうち、並列処理の対象となる複数の処理の指定を受け付ける。指定された処理は、以下「並列実行単位」という。
【0051】
割当部544は、操作部520によって受け付けられた操作と並列実行単位指定部542によって指定された並列実行単位とに基づいて、各並列実行単位と当該マルチコアプロセッサに含まれる各コアとの関連付けを行なう。関連付けられた状態を表わすデータは、記憶部530に保持される。
【0052】
実行順序指定部546は、操作部520に対する操作と割当部544によって関連付けられたデータとに基づいて、当該関連付けが行なわれた各並列実行単位の実行順序を指定する。
【0053】
生成部548は、実行順序指定部546によって指定された順序と、各並列実行単位とに基づいて、当該マルチコアプロセッサによる実行の対象となるソースコードを生成する。当該ソースコードは、モデルシミュレータとの周期毎の通信処理を含み、各コアに共通に用いられる。
【0054】
シミュレーション実行部550は、生成部548によって生成されたソースコードをマルチコアプロセッサ実行可能形式に変換して、デバッグエミュレータ等を介してマルチコアプロセッサで実行させて、モデルシミュレータとPILシミュレーションを行う。
【0055】
表示部560は、制御システムのモデルあるいは生成されたソースコードのシミュレーションの結果の入力を受け付けて、入力されたデータを表示する。表示部560は、たとえば液晶モニタ、有機EL(Electro Luminescence)モニタなどによって実現される。
【0056】
<実施例1>
実施例1は、以下に説明する一連の手順により、マルチコアで動作する並列化ソースコードを生成し、MILシミュレーションまたはSILシミュレーションにおいて機能検証を実施できる環境を提供する。この環境においては、モデルファイルからコーダによって生成される1つのソースプログラムが、複数のコアで共有され、実行される。
【0057】
一連の手順とは、たとえば、以下のような手順を含む。
(手順1)CPU1は、PILシミュレーションの対象とするコード生成範囲が選択されて指定されたことを検知する。
(手順2)CPU1は、選択範囲内において並列化単位が指定されたことを検知する。
(手順3)CPU1は、並列化単位毎にコア割当が行なわれるコアが指定されたことを検知する。
(手順4)CPU1は、コア割当が行なわれた並列化単位間の実行順序制御の指定、ならびに、制御周期毎の周期先頭及び周期終了時のコア同期の指定を検知し、コードを生成する。
(手順5)CPU1は、モデルシミュレータ上のプラントモデルとマルチコア上のコントローラプログラムとを連携したPILシミュレーションにより、実行時間情報をモニタ8に表示する。
【0058】
手順1において、ユーザは、まず、PILシミュレーションにより、マルチコアマイコンで実行したい制御周期範囲を選択する。
【0059】
手順2において、ユーザは、その選択範囲を並列実行可能な単位に分割して、分割された単位をブロックとして定義する。
【0060】
手順3において、ユーザは、並列実行単位の各ブロックについて、当該ブロックの処理を実行するコアを指定するため、当該ブロックとコアとを関連付ける。以下、並列実行単位のブロックを並列単位ブロック、コア割当が指定されたブロックをコア割当指示ブロックと呼ぶ。
【0061】
コードを実行する各コアは、各並列単位ブロックについて、関連付けられたコア割当指示ブロックで指定されるコア番号(たとえば、PE1、PE2等)と、マルチコアマイコン内の各プロセッサエレメント(PE)にハードウェア機能として保持するコア番号を読み出す。各コアは、指定されたコア番号と保持しているコア番号とを比較する。これらのコア番号が一致する場合には、当該コアは該当ブロックの生成コードを実行する条件実行文として、ソースコードを生成するように設定される。一方、これらのコア番号が一致しない場合には、当該コアは該当ブロックの生成コードを実行しないように設定される。
【0062】
さらに、この並列単位ブロックへの設定には、一制御周期で実行する複数のブロックを、複数のコアで並列実行する場合に必要な設定(たとえば、実行順序を制御するための設定)も含んでいなければならない。加えて、複数コアで一制御周期相当のコード列を実行した上で、プラントモデルとマルチコアとを連携するにあたり、一制御周期相当の開始と完了とを同期させる、コア間同期のための設定を含めなければならない。そこで、手順4において、ユーザは、そのような実行順序とコア間同期とを制御するための指定を行なう。その後、マルチコアで実行可能な並列化コードが生成される。生成された並列化コードに対して、手順5において、PCは、プラントモデルと共に連携シミュレーションを行い、マルチコア実行時の実行時間情報をモニタ8に表示する。
【0063】
[モデル適用手順]
以下、
図6から
図11を参照して、モデル例を本実施の形態に係るシミュレーション環境に適用された場合について説明する。当該モデル例は、たとえば、MATLAB/Simulinkベースのモデル例である。
【0064】
(コード生成単位の指定)
図6は、モデルからサブシステムを選択する態様を表わす図である。ある局面において、手順1に関し、たとえば、Simulink環境においては、Simulinkで提供されるSubsystemブロック機能等を用いることによって、コーダによるコード生成単位を指定することができる。
【0065】
たとえば、モニタ8は、ブロック610,620,630,640,650,660,670,680を表示している。性能検証装置500のユーザは、マウスを操作して、当該モデルの一部に相当するサブシステム690を構成する領域(コード生成範囲)を指定する。サブシステム690は、たとえば、ブロック610,620,630,640,650を含む。サブシステム690は、コード生成の対象となる。
【0066】
図7は、サブシステム690をコード生成範囲710として置き換えた状態を表わす図である。すなわち、モニタ8は、コード生成範囲710と、ブロック660,670,680とを表示し得る。
【0067】
(並列化単位の指定)
図8は、並列化単位を選択する場合における画面の表示状態を表わす図である。このフェーズでは、並列動作が可能な単位を分離し、分離した各々の単位にコア割当実行コードを生成するためのプレースホルダを設定する。プレースホルダとは、実際の内容を後から挿入できるように仮に確保される場所である。本実施の形態において、プレースホルダにコア割当制御コードを挿入するが、加えて、該当単位の計時コードを挿入してもよい。
【0068】
並列化単位の指定は、たとえば、Simulinkで提供されるEnabled Subsystemブロック機能等を用いることによって、並列動作が可能な単位を分離することにより実現される。Enabled Subsystemブロックは並列化単位に対して、コア割当制御コード等を生成するためのプレースホルダを用意することができる。
【0069】
モニタ8は、使用者による上記のための操作に基づいて、並列化単位810,820,830,840,850を表示している。使用者は、コード生成範囲710に含まれる各ブロックをそれぞれ並列化単位として選択し得る。
【0070】
図8に示される例では、ブロック610,620,630,640,650は、並列化単位810,820,830,840,850として、それぞれ指定されている。すなわち、ブロック610,620,630,640,650は、それぞれ、マルチコアプロセッサの各コアにおける並列化処理の対象として選択されている。
【0071】
並列化単位の選択に関し、たとえば、SimulinkにおけるGotoブロックとFromブロックのように対を構成する2以上のブロックは、ひとつの並列化単位に含まれるように選択する。したがって、たとえば、ある局面において、対を構成する2以上のブロックは、コード生成範囲710の外に存在し得る。あるいは、別の局面において、対を構成する2以上のブロックは、同一のコード生成範囲に含まれ得る。
【0072】
図9は、並列化単位として指定された各ブロックとその他のブロックとの関係を表わす図である。モニタ8は、並列化単位として指定されたブロック610,620,630,640,650と、出力ポート910,920,930,940,950とを表示している。
【0073】
(並列化単位ごとにコアの割当を指定)
図10は、並列化単位毎にコア割当を指定するための画面を表わしている(手順3)。手順3では、Simulinkで提供されるFromブロック機能等を用いることによって、各並列化単位に、コア識別指示を定義して接続する。Fromブロックには、接続されたEnabled Subsystemブロックを実行するコアは、コアの識別番号(たとえば、PE1,PE2等)で指定される。
【0074】
一例として、ある局面において、モニタ8は、並列化単位として指定されたブロック610,620,630,640,650と、各ブロックが実行される処理要素(PE)を表わすアイコンと、その他の出力ポート910,920,930,940,950とを表示している。より詳しくは、ブロック610とブロック630とブロック650とは、第1のPE(=PE1)1010,1030,1050の画像にそれぞれ関連付けられている。ブロック620は、第2PE(=PE2)の画像1020に割り当てられている。ブロック640は、第3PE(=PE3)の画像1040に割り当てられている。これらの割当を表わすデータは、たとえば、性能検証装置500のハードディスク5に保存される。
【0075】
(実行順序の制御等)
図11は、コア割当が行なわれた並列化単位のマルチコア実行とPILシミュレーション用コードの生成のための画面を表わしている(手順4)。すなわち、手順4として、実行順序等を制御するための以下のような処理が行なわれる。
・処理(1):並列化単位の入力および出力の有無により、ブロック間の実行順序を制御するための待ち合わせコードを、宣言コード、終了コードとして生成するための処理。
・処理(2):複数コアで一制御周期相当のコード列を実行するための、開始と完了とを同期させるコードを生成するための処理。
・処理(3):並列化単位に相当するコード列を、指定コアで実行するための、実行コア判別真偽関数の関数定義コードを生成するための処理。
・処理(4):処理(3)の結果として生成される実行コア判別真偽関数の呼び出しコードを、手順2で用意されたプレースホルダに、コア割当制御コードとして生成するための処理。
・処理(5):処理(1)〜(4)が適用されたモデルファイルに対し、手順1で指定されたSubsystemについて、コーダがソースコードを生成する処理。
【0076】
処理(1)では、並列化単位について、他のコアに割当てた並列化単位の出力信号が入力信号として存在するとき、ユーザは、出力側の並列化単位の実行を待ち合わせるコードを、宣言コードとして記述する。ユーザは、さらに、他のコアに割当てた並列化単位の入力信号となる出力信号が存在するとき、実行完了を通知するコードを、終了コードとして記述する。
【0077】
ある局面において、モニタ8は、ブロック610,620,630,640,650と、各ブロックに割り当てられたPEを表わす画像1010,1020,1030,1040,1050と、他の出力ポート910,20,930,940,950とを表示している。PE2に割当てたブロック620は、出力信号が他のコアPE1に割当てたブロック650の入力信号となるため、実行完了を通知するコード1410が終了コードとして記述されている。同様に、PE3に割当てたブロック640は、出力信号が他のコアPE1に割当てたブロック650の入力信号となるため、実行完了を通知するコード1410が終了コードとして記述されている。PE1に割当てたブロック650は、他のコアに割当てたブロック620とブロック640の出力信号が入力信号となるため、ブロック620とブロック640の実行集完了を待ち合わせるコード1420が宣言コードとして記述されている。PE1に割当てたその他のブロック610とブロック630は、他のコアに割当てた並列化単位との間に信号がないため、実行完了通知コード、待ち合わせコードともに記述されていない。
【0078】
処理(2)では、ユーザは、手順(1)により指定したコード生成単位に対し、全てのPEの同期のための待ち合わせコードを、宣言コード及び終了コードとして記述する。
【0079】
図12を参照して、並列化コードの一例について説明する。
図12は、手順4の処理(5)で生成される並列化コードの一例を表す図である。
【0080】
たとえば、コード1210は、処理(3)により生成される、関数定義コードの一部に相当する。コード1220及びコード1250は、処理(2)により生成される、複数コアでの開始と完了とを同期させるためのコードの一部に相当する。コード1230は、処理(4)により生成される、コア割当制御コードの一部に相当する。コード1240は、処理(1)により生成される、ブロック間の実行順序を維持するための待合せのコードに相当する。
【0081】
手順5では、生成された並列化コードを、PILシミュレーション用の通信IFを介して実行するように設定する。手順4により、全てのコアは一制御周期毎に開始と完了が同期されるので、PILシミュレーション用の通信IFによるモデルシミュレータとの通信は、マルチコアプロセッサ中のいずれかひとつのPEで実行することができる。このPILシミュレーション用並列化コードにより、マルチコアプロセッサ31とコンピュータ410で動作するモデルシミュレータを通信させ、連携シミュレーションを行い、一制御周期毎の実行時間が表示される。Mathworks社のrtiostream インターフェイスは、このようなPILシミュレーション用通信IFの例である。画面の表示態様については後述する。
【0082】
ここで、
図3を再び参照して、タイムチャートは、以上の各手順によって生成された並列化ソースコードの実行例を示している。モデルシミュレータ上のセンサから送信される入力信号とともに、コントローラの一制御周期の開始がマルチコアマイコンに通知されると、マルチコアマイコンに含まれる複数のコアは、複数のコアで共有するひとつの並列化プログラムを実行する。各コアは、当該コアが備えるコア識別番号と当該並列化プログラムに含まれるブロックに割り当てられたコア識別番号とを比較して、並列化プログラム中で自身が実行するべきプログラム部分を判別して実行できるように、プログラムには条件文が付加されている。たとえば、第1のコア324(PE1)で動作するプログラムは、モデルシミュレータ上のセンサ出力を受信し、第2のコア325(=PE2)と共に制御周期内に演算するべき処理を開始する。演算処理が完了すると、コア324はコア325が演算処理を完了するまで待機する。コア324とコア325とが各々の処理を完了したら、コア324はPILシミュレーション用通信IFを介して、モデルシミュレータにコントローラの一制御周期の完了を通知し、アクチュエータ330への制御量を送信する。
【0083】
以上の適用例で、生成される並列化ソースコードは、マルチコアマイコンの複数のコアが同一のプログラムコードを共有して、同一コードを実行できるように生成しているが、各コアに対し、それぞれ割当てられた並列化単位に相当するコード片を含む、非共有の異なるプログラムコードを生成させてもよい。
【0084】
さらに、以上の適用例では、各手順をMBDツールGUI(Graphical User Interface)で操作する場合で説明したが、各手順および各処理は、雛型を予め用意してブロックセットライブラリ231として提供してもよい。たとえば、手順(4)において、処理(1)〜(4)としてユーザによって操作される内容は、コア識別情報やコア個数など、マルチコアマイコンの仕様により定形的に用意できるものである。したがって、これらをブロックセットライブラリ231として予め用意して、MBDツールから利用できるように提供してもよい。
【0085】
[画面の表示]
図13を参照して、別の局面における性能検証装置500の画面の表示態様について説明する。
図13は、モニタ8が示す状態を表わす図である。
【0086】
ある局面において、モニタ8は、制御状況表示領域1310とコア配置指定領域1320と、実行時間表示領域1330とを表示している。各領域の表示の態様は、
図13に示されるものに限られない。
【0087】
制御状況表示領域1310は、性能検証装置500によって生成されたソースコードを用いて制御シミュレーションが行なわれた場合における挙動を示すグラフを表示している。コア配置指定領域1320は、先に作成されたコアとブロックとの関係を表わす画像を表示している。実行時間表示領域1330は、生成されたソースコードによって制御が実行される場合における時間を表示している。
【0088】
以上のように、実施例1に係る性能検証装置500によると、制御モデルから、複数コアに割り当てられたコントローラプログラムを生成し、一制御周期毎に実行することができ、そのときのマルチコアマイコンでの実行時間を表示することができる。
【0089】
各コアがPC上のモデルシミュレータで動作する、プラントモデルと個別に通信する方法では、コア間の排他や同期の制御と、プラントモデルとの連係通信の手順が複雑になって、連係シミュレーション速度が低下する。これに対し、プラントモデルと連係シミュレーション通信するコアが1コアである本実施例では、マルチコア間の排他や同期はマルチコアマイコン側のみで管理することができる。
【0090】
以上のように、実施例1では、GUI操作によるコア割当り指示する例や、コア割当のブロックセットライブラリを用意し、制御モデル設計者がブロック毎のコア割当をモデル上で指示する例を示したが、モデル構造から並列性を抽出することができるソフトウェアによって、割当指示を生成してもよい。非特許文献1及び非特許文献3はこのような並列性抽出技術の例であって、制御モデルから並列性を抽出する方法を提案している。
【0091】
<実施例2>
以下、実施例2について説明する。実施例1では、一制御周期に相当する、開始から最後の待ち合わせまでの全体が計測される。この態様以外に、別の局面において、制御周期内におけるコア毎の開始から、演算処理後の待ち合わせ開始までの時間を計測するようにソースコードを生成することもできる。その場合には、複数のコアのうち、処理時間が長くかかるコアを確認することができる。
【0092】
さらに別の局面において、コントローラブロックの各サブブロックの実行時間を計測するようにコード生成することもできる。その場合には、制御周期内に演算できない場合のコア割当の見直しに有用な、各サブブロックの実行時間を得ることができる。
【0093】
すなわち、開示された技術思想に基づくマルチコアPILシミュレーション環境では、
・マルチコアマイコンでの、コントローラプログラムの各制御周期の実行時間、
・同じく、各制御周期における、コア毎の演算終了までの実行時間、
・同じく、各制御周期における、サブブロック毎の実行時間、
を表示することができる。
【0094】
このようにして得られる情報は、タスク実行時間に基づいて、コア割当を行うツールにより、良好な処理時間を得られるプログラムを生成する際に利用することができる。非特許文献2は、ハードリアルタイム制約下におけるマルチコアタスク配置手法そのようなコア割当ツールの例である。非特許文献2においては、各タスクの Worst Case Response Time (WCRT)の累積値を評価関数に用いることにより、コア間依存,待ち時間率,不均衡率の各項目でバランスの取れた配置が可能であるとしている。WRCTは、タスクのジョブがリリースされてから、そのジョブが完了するまでの応答時間の最悪値であるが、マルチコアの場合はその計算が著しく困難であった。本発明によるPILシミュレーション環境では、このWRCTに相当する値を比較的容易に取得することができる。
【0095】
一方、タスク毎のWRCTを取得する場合のように、一制御周期内で計測対象区間の数が増えるほど、一般に、通信手順が増え、シミュレーション時間は長くなるので、目的に適った計測方法を選択的に指定できることが望ましい。
【0096】
選択的に指定できる計測方法の例として、実施例1においては、計測対象区間の実行時間を、マイコンのブレーク機能を用いて計測することができる。他にも、マイコンのデバッグトレース機能を用いて計測することができる。この場合には、各トレース情報に付与されるタイプスタンプ等から実行時間は、算出される。
【0097】
同様に、マイコンのパフォーマンスカウンタ機能を用いて、計測対象区間の実行時間を計測することもできる。デバッグトレース機能やパフォーマンスカウンタ機能を使用する方法では、ブレーク機能を用いる方法に比べて、制御プログラムの実行フローを中断させる回数を減らすことができるため、シミュレーション速度を速くすることができる。
【0098】
<実施例3>
以下、実施例3について説明する。実施例1は、サンプリング周波数が一つである伝統的なシングルレート信号処理を例として、プラントモデルとマルチコアで実行されるコントローラのPILシミュレーション方式を説明した。複数のサンプリング周波数が混在するマルチレート信号処理では、それらのサンプリング周波数を、周波数逓倍として制御設計することがしばしば行われる。
【0099】
実施例3は、サンプリング周波数逓倍のプラントとコントローラにおける、マルチコアPILシミュレーション方式であって、サンプリング周波数毎にコントローラモデル内を分離して、複数のサンプリング周波数のうち、リアルタイム要求が高い短周期の制御について実施例1を適用する。たとえば、短いサンプリング周波数として、もっとも短い基本周波数A1と、その2倍の周波数A2があった場合、コントローラモデル内をサンプリング周波数毎に、周波数A1のグループと周波数A2のグループに分離して、各々実施例1を適用する。マルチコアマイコン上のコントローラプログラムと、コンピュータ上のモデルシミュレータで動作するプラントモデルとは、短いサンプリング周波数の中で最大の周波数であるA2の一制御周期毎に通信して連携シミュレーションを行う。
【0100】
マルチレート信号処理においては、長いサンプリング周波数での制御には、リアルタイム要求が比較的低い、システム診断処理などがしばしば割当てられる。こうした長いサンプリング周波数の制御は、リアルタイム要件が高い制御を優先してPEに割当てた後、負荷の低いPEに割当てればよいので、前記の短制御周期のPILシミュレーションの際にはPILシミュレーション対象に含めない。
【0101】
<実施例4>
以下、実施例4について説明する。以上の実施例において、PILシミュレーションにより取得した、コントローラプログラムの制御周期毎の実行時間は、コンピュータ上でのSILシミュレーションで使用してもよい。このとき、マルチコアプロセッサではプログラムを実行せずに、該当ブロックの実行時間として、PISシミュレーションにより取得した実行時間を参照する。この方法によれば、SILシミュレーションに比べてコントローラプログラムの制御時間の見積精度は向上し、マルチコアプロセッサとのPILシミュレーションに比べて高速シミュレーションが実現できる。
【0102】
(まとめ)
モデル設計されたコントローラによって生成されたコードを、複数のCPUコアに分割し、分割による通信オーバーヘッド等の影響を含めて評価して、コントローラプログラムを構成する各タスクのコアへの配分を計画することができる。
【0103】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。