JP4906286B2 - ソフトウェア開発環境システム - Google Patents

Description

本発明は、実機を制御する制御ソフトウェアを開発するためのソフトウェア開発環境システムに関する。

実機を、例えばマイクロコンピュータ（マイコン）に組み込んだソフトウェアにより制御するといった構成の装置が、例えば家電機器分野や車両制御機器分野等において、多数存在する。以下、説明の都合上、その車両制御機器分野を例にとると、上記実機としての車両と上記制御ソフトウェアを内蔵するＥＣＵ（Electronic Control Unit）とが、上記ソフトウェア開発環境システムの対象となる。

この制御ソフトウェアの開発において重要な作業は、ロジック検証であり、例えばその制御ソフトウェアのプログラムをデバッグすることである。この場合、実機である車両そのものを実際に制御してそのプログラムをデバッグする、ということをしていたのでは、その車両が完成するまでそのデバッグは事実上行えなくなってしまう。

そこで一般には実車両なしで上記デバッグを行うということが行われており、そのために実車両に代わる擬似車両をソフトウェアにより構築して、あたかも実車両があるかのごとく振舞うシミュレータが用いられる。

なお本発明に関連する公知技術としては、下記の〔特許文献１〜３〕がある。特許文献１は、同一ＯＳ上で動作させるソフトウェアおよびハードウェアのシミュレーションについて開示し、特許文献２は、ＣＰＵ上のシミュレータ・プログラムとシミュレータ・ハードウェアとが、パソコンのシミュレータボード上で接続された構成を開示し、特許文献３では、実機デバイスおよび仮想デバイスを周辺デバイスとして用いる場合に、効率良くプログラムの検証が行える、マイコン先行プログラム開発支援用検証システムを開示している。

特開２００２−１７５３４４号公報 特開２００１−３３１３４６号公報 特開２００３−３１６６０３号公報

図８は従来のソフトウェア開発環境システムの第１例を示す図であり、いわゆるＨＩＬＳ（Hardware In the Loop Simulation）環境システムである。本図において、参照番号１および５はそれぞれ、前述したＥＣＵおよび擬似車両である。

ＥＣＵ１は、開発対象の制御ソフトウェア２と、この制御ソフトウェア２に入力を与えると共にその入力に対するプログラム処理の結果を出力するマイコン３と、マイコン３に対し擬似車両５側からの入力を印加しまた上記の処理結果を擬似車両５側に出力するＥＣＵ回路４とからなる。

一方、擬似車両５は、実車両をソフトウェアにより構成した車両モデル６ｍと、この車両モデル６ｍからの出力データをアナログの電気信号に変換して、ＩＯボード８を介しＥＣＵ１側に入力し、また、ＥＣＵ１側から出力されたアナログの電気信号を、そのＩＯボード８を介して受信し車両モデル６ｍへの入力データに変換するデバイス（マイコン３に相当）７とからなる。

図９は従来のソフトウェア開発環境システムの第２例を示す図であり、いわば仮想環境システムであって全ての構成要素がソフトウェアよりなる。すなわち図８の非ソフトウェア構成要素（３，４，７および８）が、ＥＣＵ１においてはマイコンモデル３ｍおよびＥＣＵモデル４ｍとしてソフトウェア化され、一方擬似車両５においては、デバイスモデル７ｍおよびボードモデル８ｍとしてソフトウェア化される。したがって、図８に示す電気信号は、その電気信号相当の「１」「０」のデータ信号となる。

上述した従来のソフトウェア開発環境システムの第１例（図８）および第２例（図９）にはそれぞれ利害得失があり、これを示すと図１０のとおりとなる。図１０は従来システムの第１例（ＨＩＬＳ環境）と第２例（仮想環境）の利点（ＯＫ）と欠点（ＮＧ）とを一覧表にて示す図である。

図１０に示すとおり、「デバッグ機能」に関しては第２例（仮想環境）の方が優れ（ＯＫ）、「実行時間」に関しては第１例（ＨＩＬＳ環境）の方が優れているが（ＯＫ）、「システム構築の時間・コスト」については第１例も第２例も共に好ましくない（ＮＧ）。

上述のとおり、ソフトウェア開発環境システムの主たる目的は、開発対象であるソフトウェアのロジック検証であるから、「デバッグ機能」に関して良好でない（ＮＧ）上記第１例（ＨＩＬＳ環境）を採用するのは得策ではない。したがってその「デバッグ機能」に関して良好（ＯＫ）である上記第２例（仮想環境）の方を採用するのが有効である。

ところがこの第２例（仮想環境）は「実行時間」に関して良好でない（ＮＧ）。つまりデバッガを使用することができるものの、デバッグの実行時間すなわちマイコンモデル３ｍの動作時間、結局はソフト開発時間が、非常に長くなるという欠点がある。これは、上記マイコン３ｍのハードウェア的な動作を全てソフトウェアで実現するときに、アセンブラ言語で展開したプログラムによる動作結果をクロック単位で１つ１つ忠実に再現しているからであり、制御ソフトウェアの開発ということに特化して考えると、無駄な動作を大量に含むことになるからである。

したがって本発明は、上記従来例の問題点に鑑み、「システム構築の時間・コスト」、「デバッグ機能」および「実行時間」の全てにおいて優れたソフトウェア開発環境システムを提供することを目的とするものである。

図１は本発明に係るソフト開発環境システムの原理構成を示す図である。この原理構成は、前述した図９の構成と対比するとその違いは顕著であり、図９におけるマイコンモデル３ｍ、ＥＣＵモデル４ｍ、ボードモデル８ｍおよびデバイスモデル７ｍを全て取り去った構成となっている。この構成は図９と同様に「全ソフトウェア型」ではあるが、その図９の構成よりも極端に簡素化されている。いわば「簡易型仮想環境システム」を構築している。

この図１の構成においては、ハードウェア動作の模擬は対象外とする。したがって当然前述した電気信号相当の部分も存在しない。しかしそれに代えて、システム管理モジュール１２を新たに導入する。このシステム管理モジュール１２は制御ソフトウェア２と車両モデル６ｍとの間の情報伝達を一元管理する。このような簡素化を実現できるのは、開発対象である制御ソフトウェアの評価のみに特化することによって、上述のようにハードウェア動作の模擬を省略することができるからである。つまり制御ソフトウェア２の開発に目的を絞ったからである。このため、上記のマイコンモデル３ｍやＥＣＵモデル４ｍの動作は模擬の対象から外され、制御ソフトウェア２のデバッグ（最少限の目的）に集中させることができる。

上記のようにハードウェア動作の模擬を対象外とすることができたのは、予めハードウェアは完全に正常なものという前提を置いたからである。つまり開発対象のソフトウェアをハードウェアから完全に切り離し、そのソフトウェアの検証に特化したものである。この場合、上記のハードウェアが完全に正常なものという前提が成立していなかったとしても特段問題はないことに着目している。なぜなら、開発が完了したソフトウェアは最終的には実際にハードウェアと組み合わせた形でのチェックが行われ、ハードウェアとの整合性が確認されるので、ハードウェアに仮に異常があったとしても、この異常がこの最終段階で発見できるからである。

図２は本発明に係るソフトウェア環境システムの基本構成を示す図である。なお全図を通じて同様の構成要素には同一の参照番号または記号を付して示す。

本図において参照番号１０が本発明に基づくソフトウェア開発環境システムであり、実機（車両）を制御する制御ソフトウェア２を開発するためのソフトウェア開発環境システムである。このシステム１０は、大別して、３大モジュールすなわち制御ソフトウェアモジュール１１と、システム管理モジュール１２と、実機（車両）モデルモジュール１３とからなる。

ここに実機モデルモジュール１３は、実機（車両）を模擬した実機モデルをソフトウェアにより構成したものであり、
制御ソフトモジュール１１は、その実機モデルとの間の入力／出力情報（ＩＯ情報）に基づいて、開発対象の制御ソフトウェア２を実行するものであり、
システム管理モジュール１２は、実機モデルモジュール１３と制御ソフトモジュール１１との間に介在して、当該ソフトウェア開発環境システム全体の動作を管理するものである。

上記３大モジュール（１１，１２，１３）のうち、特に本発明を特徴付けるモジュールは、図１にも示したシステム管理モジュール１２である。その特徴は次のとおりである。すなわちシステム管理モジュール１２は、（ｉ）当該ソフトウェア開発環境システム１０内に発生する各イベントを集約する。（ii）そして、その集約した各該イベント毎にそれぞれを起動すべき時刻を設定して管理する。（iii）さらに、各該イベント毎に各該時刻の順に時系列で、制御ソフトモジュール１１および実機モデルモジュール１３を起動し動作させる。つまり、対象モジュール（１１，１３）は、モジュール１２により管理された時刻をパラメータとして制御対象のイベントを起動し、動作する。

この場合上記のイベントは、制御ソフトウェア２の評価のみに特化したときに実行すべきイベントとする。

本発明によれば、図１から理解されるように、ハードウェア部品の手配やワイヤハーネス等の作成は一切不要であり、また、制御ソフトモジュール１１と実機モジュール１３との間でやりとりされるＩＯ情報はソフト開発に必要な情報のみに絞っているので、システム（１０）を構築する時間・コストは大幅に低減される。

さらに仮想環境であるから実時間の処理はなく、デバッガ例えばＩＣＥ（In Circuit Emulator）のようなラインデバッガの使用が可能となる。

さらにまた、時刻管理されたイベントの発生タイミングに次々と移って各イベント処理を行うから、つまりある時刻のイベント処理から次の時刻のイベント処理へと処理をスキップさせるから、前述した図９のマイコンモデル３ｍが行うようなクロック単位の精密な処理のほとんどが省略され、前述した実行時間は大幅に短縮される。結局、前述した図１０の一覧表における３つの全ての項目が“ＯＫ”となる。

図３は図２における制御ソフトモジュール１１の具体例を示す図である。ただし図２の構成の中に、組み込み用マイコンの中身として展開して示す。

図３の右端に示す「パルス入力」２８−１は、車両モデルの場合、例えばエンジン回転数やスピードセンサ信号等である。このパルス入力２８−１は、キャプチャ機能部２４に入力される。キャプチャ機能部２４は、フリーランで動作するシステムタイマ２１のタイマ情報をもとに、指定したパルスの有効エッジの時刻を捉える。この時点で割込みも起こすことができる。またそのキャプチャ時刻はＩＯデータ部２３に書き込まれる。

上記の割込みが発生したときは、割込みコントローラ２２を介して、制御ソフト２内の該当の割込みルーチンが走る。

コンペア機能部２５は、例えば現在時刻から１ms後に所定のパルスを「パルス出力」２８−２として送出する、といったような制御を行うときに、その１ms後の時刻に一致したか否かを判定し、一致がとれたときにその所定のパルスを出力する。このとき割込みコントローラ２２へ割込みを指示することもできる。なお、その「パルス出力」２８−２は、車両モデルの場合、例えば点火信号や燃料噴射信号である。その点火時期や噴射時期は、最新のエンジン回転数に応じて、制御ソフトウェア２により演算され、更新される。

また通信機能部２６は、「シリアル通信」２９−１を介して、例えば外部のインテリジェントＩＣと通信を行い、必要に応じて割込みを生じさせる。さらにまたポート機能部２７は、ＩＯポート２９−１の入力ポートよりデータを読み込み、またその出力ポートよりデータを出力する。このＩＯポート２９−２には、例えば外部のＩＧスイッチ、スタータスイッチやエアコンのマグネットクラッチ等が接続する。

次に図２に示す基本構成について、さらに詳しく説明する。図４は図２におけるモジュール１１，１２および１３の具体的構成を示す図である。図４において、参照番号３０は単一のＣＰＵボードを示しており、したがってソフトウェア開発環境システム１０（図２）は、同一のパソコン上で実現される。つまり本システム１０は、好適には、実機（車両）モデルモジュール１３と、制御ソフトモジュール１１と、システム管理モジュール１２とが、同一のＯＳのもとでかつ同一のＣＰＵ上で動作するモジュールである。本システム１０全体は、システム管理モジュール１２により制御され、制御ソフトモジュール１１と実機（以下、「車両」とも称す）モデルモジュール１３の各管理対象モジュールは、システム管理モジュール１２により起動される。また、制御ソフトモジュール１１と車両モデルモジュール１３との間の入力／出力（Ｉ／Ｏ）情報の受渡しは、このシステム管理モジュール１２を経由して行われる。このＩ／Ｏ情報には、モジュール１１および１２間に図示する“起動（イベント時刻付）”や“ＩＯデータ（時刻付）”や“ＩＯデータ”が含まれる。またそのＩＯ情報には、モジュール１２および１３の間においても図示するとおり、“起動（時刻付）”や“ＩＯデータ（時刻付）”や“ＩＯデータ”が含まれる。

中央のシステム管理モジュール１２は、前述したように、制御ソフトモジュール１１および車両モデルモジュール１３の各対象モジュールの起動を少なくとも制御し、まず、前述の時刻を生成するシステムタイマ２２を包含する。ここに生成された時刻は当該ソフトウェア開発環境システム（１０）全体の基準時刻をなす。したがって各対象モジュール１１および１３は、共に同一の仮想時間上で共通タイミングにて動作する。ここに、上述のイベントやＩＯデータにそれぞれ「時刻付」とした意義がある。このシステムタイマ２１は、前述した時系列の順で直近に発生するイベントを選択し、かつ、その選択したイベントに設定された時刻に本システムタイマ２１の時刻を更新する。

システム管理モジュール１２はさらに、車両モデルモジュール１３と制御ソフトモジュール１１とにより共有される共有メモリ３２を備え、車両モデルモジュール１３および制御ソフトモジュール１１から要求される各イベントを集約してシステムタイマ２１により更新される時刻を各該イベントに設定して共有メモリ３２に蓄積する。この共有メモリ３２は、下記の入力／出力（ＩＯ）ドライバと協働する。このＩＯドライバは実機環境と同一のインタフェースを有し、上記ＩＯ情報を共有メモリ３２に伝達する。

すなわちシステム１０は、制御ソフトモジュール１１および車両モデルモジュール１３内にそれぞれ形成され、上記の共有メモリ３２との間で、各イベントに関する時刻付のＩＯデータを書き込みまたは読み出す、制御ソフトモジュール側ＩＯドライバ３１および車両モデルモジュール側ＩＯドライバ３３を備える。

上記の、共有メモリ３２と、ＩＯドライバ３１および３３との間の連携において、第１の連携（点線枠３５）では、ＩＯデータを、システムタイマ２１の時刻と関連付けて、管理する。したがってこの第１の連携３５においては、例えば図３に示す「パルス入力」２８−１のデータや「パルス出力」２８−２のデータを扱うことになる。一方第２の連携（点線枠３６）では、システムタイマ２１の時刻が付されないタイミング非依存のＩＯデータを管理する。したがってこの第２の連携３６においては、例えば図３に示す「シリアル通信」２９−１のデータや「ＩＯポート」２９−２のデータを管理する。

なお図４において、ＣＰＵボード３０には、本システム１０の他に、前述のＯＳ（３７として示す）や前述のＣＰＵに付帯するＣＰＵタイマ（３８として示す）が搭載される。以下、図を参照しながら、ソフトウェア開発環境システム１０における具体的な一動作例を説明する。

図５はソフトウェア開発環境システム１０における具体的動作例を表すタイミングチャートであり、
図６は図５における各時刻でのイベント管理について説明するための図である。

図５において、（ａ），（ｂ），（ｃ）および（ｄ）の各欄はそれぞれ、システム管理モジュール１２、制御ソフトモジュール１１、車両モデルモジュール１３、システムタイマ２１および上述した時系列での時刻に対応する。これらの時刻はｔ０，ｔ１，ｔ２，ｔ３，ｔ４およびｔ５として示され、各時刻対応のイベント管理の内容が図６に示される。

図５および図６を参照すると、システム管理モジュール１２は「１ms割込み」を内部で生成し、自内のシステムタイマ２１が指定する時刻ｔ０において、該「１ms割込み」を発生させる。これに応じて各モジュール１１および１３を起動後、次回タイミングを設定する。

上記の各モジュール１１および１３の起動に基づき、制御ソフトモジュール１１は「１ms処理」を起動し、また、車両モデルモジュール１３は「メイン処理」を起動する。なお、これらモジュール１１および１３はそれぞれ「定時処理」を繰り返し実行しており、各該定時処理の起動のために上記「１ms割込み」が発生する。

上記「１ms割込み」を受けた制御ソフトモジュール１１は上記の「１ms処理」を実行し、その中で、システム管理モジュール１２は、図５のａ１にて、何らかの出力例えば「ＩＯ操作」（例えばＩＯパルスの出力等）をＩＯドライバ３１を経由して自内の共有メモリ３２にセットしながら「イベント管理の更新」を行う。車両モデルモジュール１３での「メイン処理」（１ms処理）においても、図５のａ２にて、「ＩＯ操作」が発生し、「イベント管理の更新」が行われて、共有メモリ３２にイベントが蓄積する。

時刻ｔ０での車両モデルモジュール１３による「メイン処理」にて、システム管理モジュール１２が該モジュール１３より「パルス１」出力要求を受けたものとすると、これに対応するパルス発生時刻を設定する。ここに時刻ｔ１にて、「パルス１」出力が発生し、制御ソフトモジュール１１による「パルス１出力」処理が起動する。なおここでは（図５の“ｂ１”）、モジュール１１は、モジュール１２内のシステムタイマ２１のタイマ値を基に演算を実行する。演算とは、例えば最新のエンジン回転数を検出し、その回転数の変化に応じた次回タイミングの算出を行うことである。

モジュール１２は、時刻ｔ１でのモジュール１１による「パルス１」出力処理により、モジュール１１から「パルス２」出力要求を受けたものとすると、更新したシステムタイマ２１のタイマ値をパラメータとして（図５の“ａ３”）、これに対応するパルス発生時刻を設定する。ここに時刻ｔ２にて、モジュール１１による「パルス２」出力処理が起動する。

一方、車両モデルモジュール１３から「パルス３」出力要求をモジュール１２が受けたものとすると、これに対応するパルス発生時刻をモジュール１２が設定する。ここに時刻ｔ３にて、「パルス３」入力が発生し、モジュール１１による「パルス３入力」処理が起動する。

次にモジュール１２は、モジュール１１からの「パルス４」出力要求を受けたものとすると、これに対応するパルス発生時刻を設定する。ここに時刻ｔ４にてモジュール１１による「パルス４」出力処理が起動する。

時刻ｔ５では、通信仕様に応じてモジュール１２内部で生成された「受信イベント」が発生したものとすると、これに応答してモジュール１１は、それに対応した「受信」処理を起動する。

以上の図５および図６の説明は１つの例示であるが、特に図５において注目すべき点は、第１に、各モジュールの処理中の時間が零であることである。例えば、時刻ｔ０のステップについて見てみると、図示するＴはＴ＝０である。また第２に、イベントの発生がない区間は、処理をスキップしながら、時系列で順番にイベントを実行していくことである。これは図５に表すように、「階段状」に時刻が進む様子から明らかである。

上述の第１の点、すなわちＴ＝０に関してみると、逆に、Ｔ＝０であるから実際の処理時間の計測が行えない。つまり、対象モジュール（１１，１３）の各々の「処理起動時から処理終了時まで」の実処理時間が分からない。このことは、デバッガについてみると、処理中断しない場合（ステップ実行しない場合）の処理時間の推定ができないことにもなる。

そこで、かかる不都合を解消した処理負荷計測機能を実現するために、本発明では、所定のＯＳ（図４の３７）で動作するＣＰＵに具備されるＣＰＵタイマ（図４の３８）による実時間を用いて、システムタイマ２１により規定される１単位の時刻（ｔ０，ｔ１，ｔ２等）内で処理されるイベントの実処理時間を計測するようにする。

以上の説明から明らかなとおり、本発明のソフトウェア開発環境システム１０を動作させる主体はシステム管理モジュール１２である。そこでこのモジュール１２の動作についてさらに説明を補足しておく。

図７はシステム管理モジュール１２の処理例を示すフローチャートである。本フローチャートにおいて、
ステップＳ１１：先の図６に例示されるような種々のイベント管理情報を基にして、直近のイベントを選択する。例えば図５の時刻ｔ０のステップにあっては、直近のイベントは時刻ｔ１のイベントである。

ステップＳ１２：上記の選択した直近のイベントの時刻（上記の例でｔ１）に、システムタイマ２１の時刻を更新する。

ステップＳ１３：該当システムタイマ時刻（上記の例でｔ１）で更新されるＩＯデータを、ＩＯドライバ（図４の３１）にセットして、制御ソフトモジュール１１を起動する。

ステップＳ１４：発生するイベント情報例えば割込みフラグを所定のレジスタに設定する。

ステップＳ１５：上記の発生するイベントに対する該当のモジュールを起動する。そして上記の割込みフラグを見て、実行すべき処理を選択する。この処理にて、上記ＩＯデータを用いて演算を行う。

なお、上記ステップＳ１５と、後述するステップＳ１７での各処理は（図７の１１／１３参照）、制御ソフトモジュール１１あるいは車両モデルモジュール１３内での処理である。

ステップＳ１６：モジュール１１あるいは１３内からの要求により、ＩＯ情報の更新やイベント管理情報の更新を行う（図５において、ａ１ならびにａ２における前述した「ＩＯ操作」や「イベント管理の更新」参照）。

ステップＳ１７：かくして処理済みとなったイベントは、ステップＳ１１のイベント管理情報から削除する。

以上詳述した本発明に係るソフトウェア開発環境システム１０は、図３に示す３つの項目について全て“ＯＫ”という優れた機能を発揮するものの、逆に、その原理故に不都合が生じる場合もある。

これは、制御ソフトモジュール１１内及び／又は車両モデルモジュール１３内のアプリケーションに「時間待ちの処理」を含む場合である。このような場合、本発明のシステム管理モジュール１２は、これらモジュール（１１，１３）のいずれかから、当該「時間待ちの処理」に起因するシステムタイマ２１への参照要求が連続して発生したことを検知して、システムタイマ２１の時間を所定時間進ませることとする。

ここに上記の「時間待ちの処理」とは、例えば
ステップＳ２１：まず最初に時刻を取得し（例えば初期値時刻ｔ（１）をｔ０とする）、
ステップＳ２２：続いて若干のインターバルをおいて第２回目の時刻ｔ（２）を取得し、
ステップＳ２３：その第２回目の時刻ｔ（２）が、例えばｔ０＋１msを超えたか否か判別し、そのｔ０＋１msを超えていなければ第３回目、第４回目…の時刻ｔ（３），ｔ（４）…を取得し、ｔ０＋１msを超えるまで本ステップＳ２３を反復する、
といったプログラムである。

このような「時間待ちの処理」のプログラムがアプリケーションの中に含まれる場合には、上記のステップＳ２３にて、対象モジュール（制御ソフトモジュール１１／車両モデルモジュール１３）は、上記の１msの経過を、システム管理モジュール１２内のシステムタイマ２１を何回も参照しながら待つことになり、素早くそのステップＳ２３から抜け出すことができない。

このような参照要求が多発する状況になると、モジュール１２は、ある何らかのアプリケーションが、システムタイマ２１のタイマ値が進むことを期待していることを知るので、自内のシステムタイマ２１の時間を所定時間だけ、一度にあるいは少しずつ、進ませる。これにより、上記ステップＳ２３の繰り返しループから短時間のうちに抜け出ることができる。このようにシステムタイマ２１の時間を任意に進めても（あるいは遅らせても）、前述のとおりシステムタイマ２１の時間は常に当該ソフトウェア開発環境システム（１０）全体の基準タイマとなるので、他のモジュール１１および１３に何ら問題は起こらない。

以上述べてきたように本発明によれば、図１０に掲げるシステム構築の時間・コスト、デバッグ機能および実行時間の全てにおいて優れたソフトウェア開発環境システムが実現される。

本発明に係るソフトウェア開発環境システムの原理構成を示す図である。 本発明に係るソフトウェア開発環境システムの基本構成を示す図である。 図２における制御ソフトモジュール１１の具体例を示す図である。 図２におけるモジュール１１，１２および１３の具体的構成を示す図である。 ソフトウェア開発環境システム１０における具体的動作例を表すタイミングチャートである。 図５における各時刻でのイベント管理について説明するための図である。 システム管理モジュール１２の処理例を示すフローチャートである。 従来のソフトウェア開発環境システムの第１例を示す図である。 従来のソフトウェア開発環境システムの第２例を示す図である。 従来のソフトウェア開発環境システムの第１例および第２例の利害得失を示す図である。

符号の説明

１ ＥＣＵ
２ 制御ソフトウェア
５ 擬似車両
６ｍ 車両モデル
１０ ソフトウェア開発環境システム
１１ 制御ソフトウェアモジュール
１２ システム管理モジュール
１３ 実機（車両）モデルモジュール
２１ システムタイマ
３０ ＣＰＵボード
３１ 制御ソフトウェアモジュール側ＩＯドライバ
３２ 共有モメリ
３３ 実機（車両）モデルモジュール側ＩＯドライバ
３５ 第１の連携
３６ 第２の連携
３７ ＯＳ
３８ ＣＰＵタイマ

Claims (5)

1. 実機を制御する制御ソフトウェアを動作させ、前記制御ソフトウェアのロジック検証を行うためのソフトウェア開発環境システムであって、
   前記実機を模擬したモデルであってソフトウェアで構成した実機モデルを実行する実機モデル処理手段と、
   前記実機モデルとの間の入力／出力情報に基づいて、ロジック検証対象の前記制御ソフトウェアを実行する制御ソフト処理手段と、
   前記実機モデル処理手段と前記制御ソフト処理手段との間に介在して、当該ソフトウェア開発環境システム全体の動作を管理するシステム管理処理手段と、を備え、
   前記実機モデル処理手段と前記制御ソフト処理手段及び前記システム管理処理手段は、演算処理装置上でソフトウェアを動作させる形で構成され、
   前記システム管理処理手段は、
   前記実機モデル処理手段と前記制御ソフト処理手段での演算の結果、発生する各イベントを集め、集めた複数のイベントを、イベント毎に設定したそれぞれのイベントを起動すべき時刻と共に管理し、管理している複数のイベントを、イベント毎に設定された時刻の順に時系列で選択し、前記制御ソフトウェアと前記実機モデルの少なくとも一方における、選択したイベントで動作が必要な処理手段を起動させることで、前記制御ソフト処理手段および前記実機モデル処理手段を起動し動作させるイベント管理処理と、
   当該ソフトウェア開発環境システム内の基準時刻を生成するシステムタイマを管理するシステムタイマ管理処理と、を行う処理手段であり、
   前記実機モデル処理手段と前記制御ソフト処理手段は、前記システムタイマで生成される基準時刻に基づいて演算を行い、
   前記システム管理処理手段は、前記イベント管理処理にて管理するイベントとして、前記実機モデル処理手段又は前記制御ソフト処理手段からの要求によって生成するイベントと、当該システム管理処理手段の内部で生成するイベントとが存在し、前記イベント管理処理にてイベントを選択して処理手段の起動を行う際に、選択したイベントに対応して設定されている時刻に、前記システムタイマの時刻を更新することを特徴とするソフトウェア開発環境システム。
2. 前記実機モデル処理手段と前記制御ソフト処理手段における演算に必要な入力／出力情報を受け渡しするためのメモリで、前記実機モデル処理手段と前記制御ソフト処理手段とがそれぞれ書き込みと読み出しが可能な共有メモリを備え、
   前記システム管理処理手段は、前記実機モデル処理手段又は前記制御ソフト処理手段によって前記共有メモリに入力／出力情報を書き込む処理が行われると、書き込まれた入力／出力情報からイベントの発生要求を取得し、前記イベント管理処理にて管理するイベント管理に関する情報を更新する処理を行うことを特徴とする請求項１記載のソフトウェア開発環境システム。
3. 前記システム管理処理手段が前記イベント管理処理にて管理するイベントに関するイベント管理情報は、前記共有メモリに蓄積されており、
   前記実機モデル処理手段と前記制御ソフト処理手段は、前記システム管理処理手段からイベントに基づいて起動されると、起動される元となったイベントに対応する処理を行うとともに、処理が完了すると処理済のイベントを前記イベント管理情報から削除することを特徴とする請求項２記載のソフトウェア開発環境システム。
4. 前記実機モデル処理手段と前記制御ソフト処理手段はそれぞれＩＯドライバを備えており、
   前記システム管理処理手段は、前記実機モデル処理手段又は前記制御ソフト処理手段をイベントに基づいて起動する際に、起動する際に更新するシステムタイマの時刻で更新される入力／出力情報を、前記ＩＯドライバにセットし、
   前記実機モデル処理手段と前記制御ソフト処理手段は、前記システム管理処理手段からイベントに基づいて起動されると、前記ＩＯドライバにセットされた入力／出力情報を用いてイベントに対応する処理を行うことを特徴とする請求項２記載のソフトウェア開発環境システム。
5. 前記システム管理処理手段内部で生成するイベントは、システムタイマの基準時間が所定時間経過する毎に発生する割込みイベントであることを特徴とする請求項１記載のソフトウェア開発環境システム。

Images