(57)【要約】【課題】階層化，部品化されたソフトウェアの開発において、ソフトウェア資産の結合方法を効果的に選択することが可能な手段を提供することにある。【解決手段】制御ソフトウェア開発ツール１０２によって作成される制御ソフトウェア１０１は、制御演算処理を行うアプリケーション１０３とソフトウェア部品同士の接続を行う接続層１０４と基本ソフトウェア１１４から構成される。従来のソフトウェア構成では、基本ソフト内で階層化したソフトウェア部品間の結合は、標準Ｉ／Ｆ１０８で記述され、ソフトウェア部品間の結合方法をソフトウェアの設計変更に併せて柔軟に変更することは困難であった。本発明では、ソフトウェア部品間の結合方法に、テンプレート記述を用いることでソフトウェア部品の結合方法の柔軟な選択を可能とする。【選択図】  図１
2010237895.tif 000002
【特許請求の範囲】
【請求項１】
車載機器への入出力処理を行うための基本ソフトウェア部を備える車載電子制御装置であって、
前記基本ソフトウェア部は複数の処理部と、
前記処理部間の入出力の関係を保持するテンプレートを有したテンプレートインターフェース部とを備えることを特徴とする車載電子制御装置。
【請求項２】
請求項１に記載の車載電子制御装置であって、
前記車載電子制御装置は内部データを出力するための観測点を備え、
前記観測点は前記テンプレートインターフェース部によって設定されていることを特徴とする車載電子制御装置。
【請求項３】
請求項２に記載の車載電子制御装置であって、
前記車載電子制御装置は前記観測点から得られる前記内部データを出力するための観測端子を有することを特徴とする車載電子制御装置。
【請求項４】
請求項２または３に記載の車載電子制御装置であって、
前記車載電子制御装置は前記車載機器を制御するためのアプリケーションを備え、
前記観測点からは前記アプリケーションが前記車載機器を制御するタイミングの情報が出力されることを特徴とする車載電子制御装置。
【請求項５】
請求項１から４いずれか一項に記載の車載電子制御装置であって、
前記入出力の関係はコンフォーマンスクラスの情報によって決定されることを特徴とする車載電子制御装置。
【請求項６】
請求項１から５いずれか一項に記載の車載電子制御装置であって、
前記入出力の関係は前記車載電子制御装置に搭載するハードウェアの情報によって決定されることを特徴とする車載電子制御装置。
【請求項７】
車載機器への入出力を行うための基本ソフトウェア部を備えた
前記車載機器の制御を行うための制御ソフトウェアであって、
前記基本ソフトウェア部は複数の処理部と、
前記処理部間の入出力の関係を保持するテンプレートを有したテンプレートインターフェース部とを備えることを特徴とする制御ソフトウェア。
【請求項８】
請求項７に記載の制御ソフトウェアであって、
前記制御ソフトウェアは前記基本ソフトウェア部内の内部データを出力するための観測点を有し、
前記観測点は前記テンプレートインターフェース部の記述によって設定されることを特徴とする制御ソフトウェア。
【請求項９】
請求項８に記載の制御ソフトウェアであって、
前記制御ソフトウェアは前記車載機器を制御するためのアプリケーションを備え、
前記観測点からは前記アプリケーションが前記車載機器を制御するタイミングの情報が出力されることを特徴とする制御ソフトウェア。
【請求項１０】
請求項７に記載の制御ソフトウェアであって、
前記入出力の関係はコンフォーマンスクラスの情報によって決定されることを特徴とする制御ソフトウェア。
【請求項１１】
車載機器への入出力を行う基本ソフトウェア部を備えた
車両用の制御ソフトウェア作成を支援する開発ツールであって、
前記開発ツールはユーザから入力される設定情報から、
あらかじめ用意されたテンプレートを用いて
前記基本ソフトウェア部が有する複数の処理部間の入出力の関係を
保持するテンプレートインターフェース部を作成する開発ツール。
【請求項１２】
請求項１１に記載の開発ツールであって、
前記制御ソフトウェアの内部データを出力するための観測点を前記テンプレートで記述することを特徴とする開発ツール。
【請求項１３】
請求項１１または１２に記載の開発ツールであって、
前記設定情報にはコンフォーマンスクラスの情報が含まれることを特徴とする開発ツール。
【請求項１４】
請求項１１または１２に記載の開発ツールであって、
前記設定情報には前記制御ソフトウェアが信号の入出力を行うハードウェアの情報を含むことを特徴とする開発ツール。
【請求項１５】
請求項１１または１２に記載の開発ツールであって、
前記テンプレートの記述には文字列置換を用いることを特徴とする開発ツール。
【請求項１６】
請求項１１または１２に記載の開発ツールであって、
前記制御ソフトウェア中の車両制御に関わるパラメータを設定することを特徴とする開発ツール。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は車載電子制御装置，制御用ソフトウェアおよび制御ソフトウェアの開発ツールに係り、特にソフトウェア部品の組み合わせ方法に関する。
【背景技術】
【０００２】
自動車エンジン制御などの制御装置として、中央演算装置，ＲＯＭ，ＲＡＭ，入出力信号処理装置などを内蔵したマイクロコントローラ（以下マイコンと表記）が用いられている。マイコンに搭載されるソフトウェアは制御対象が目的とする制御動作を行うように、一般的には制御処理を行うアプリケーションプログラムと入出力を行うデバイスドライバやオペレーティングシステム（ＯＳ）などによって構成されている。
【０００３】
一方、近年ソフトウェアの規模の増大に伴い、個別の制御システムについてアプリケーションプログラムと入出力を行うデバイス制御プログラムとを全て開発することが困難になっており、ソフトウェアを小さな単位の部品として構成しこれを再利用する手法や、これらを階層化し変更箇所を局所化する、などの手法が採用されている。また、これらのソフトウェアの部品を資産として蓄積し、開発対象の電子システムのネットワークの構成に応じて部品を組み合わせて開発する手法が採用されている（例えば、特許文献１参照）。
【０００４】
制御システムの開発効率を向上するための一般的な手法においては、ソフトウェアを搭載するマイコンや、使用するセンサ，アクチュエータなどの構成による変更を局所化するために、ハードウェアやネットワーク構成の差異を吸収する基本ソフトウェア層と、制御に関わる論理的な処理を行う制御アプリケーション層とに分離し、変更箇所を局所化する手法が採用されている。さらに上記基本ソフトウェア層をマイコン，ネットワーク，記憶装置、などの要素毎の部品に分割することで、さらなる局所化が可能になり、既存のソフトウェアを部品単位で再利用すること、複数の開発者が並行して開発することが可能となっている。
【０００５】
また、上記の構成において、部品間のインターフェースを定義し、開発者間でその情報を共有し、複数の開発者がソフトウェアの部品をオブジェクト形式で提供したものを統合時にリンクすることも可能であり（例えば、非特許文献１参照）、これを用いれば各開発者の設計資産であるソースコードを開示することなく、ブラックボックスとして制御システムを開発することができるため、複数の独立した事業主体による分業が可能となる。また、ユーザの入力情報をパラメータとして設定することも行われている（例えば、非特許文献２参照）。
【０００６】
しかし、上記のような構成のソフトウェアを、複数の異なる事業主体の成果物を統合して開発する際に、ソースコードが開示されていない場合、デバッグ，保守，性能計測に困難を生じる。一般的なソフトウェアの不具合解析には、ソフトウェア部品間のデータの正当性をデータフローの順を追って確認するが、設計情報が開示されていない個所については、その内部情報を取得できないことがその一例である。また、性能解析，タイミング解析を行う際には、個別部品の処理時間の計測が必要になるが、ブラックボックスの部品の実行時間などを解析することは困難である。さらに、個別のソフトウェア部品の開発時に、ソフトウェア全体を統合する段階において必要となるデータやタイミングを製品開発毎に変更することは、結果として全てのソフトウェア部品を変更・確認する必要を生じさせるため、ソフトウェア部品を再利用しながら開発効率を向上することと両立できない。また、使用する可能性のあるデータやタイミングを全て開示することは、事業主体のソフトウェアの設計に関わる情報を開示することに繋がるため、複数の独立した事業主体が、各々の設計資産を維持しながら分業を進める障害となる。
【０００７】
また、車載ソフトウェアの標準化が試みられている場合に、標準化へどれだけ準拠させるかは、顧客・製品等によって異なる。従って、開発を効率良く進めるには、事業主体毎のソフトウェア資産を結合する際に、顧客の要望にあわせて標準化への準拠度合いやソフトウェア部品の接続方法を柔軟に切り替える必要がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特許第３６８８２２４号公報
【特許文献２】特許第３４６０５９３号公報
【非特許文献】
【０００９】
【非特許文献１】Apache Velocity Project (http://velocity.apache.org/)
【非特許文献２】Java API for XML Processing (https://jaxp.dev.java.net/)
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上記のように、階層化，部品化されたソフトウェアの開発において、従来はソフトウェア資産を自由に組み合わせて再利用できないといった課題があった。本発明の課題は、これらソフトウェア資産の結合方法を効果的に選択することが可能な手段を提供することにある。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、本発明の、
車載機器への入出力処理を行うための基本ソフトウェア部を備える車載電子制御装置は、
前記基本ソフトウェア部は複数の処理部と、
前記処理部間の入出力の関係を保持するテンプレートを有したテンプレートインターフェース部とを備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、ソフトウェア資産をシステムに統合する時に、ソフトウェア資産の結合方法を効果的に選択することが容易となる。
【図面の簡単な説明】
【００１３】
【図１】ソフトウェアの構造を示した図である。
【図２】ハードウェアの構造を示した図である。
【図３】アナログ／デジタル変換のタイミングを示した図である。
【図４】ハードウェアとソフトウェアの配置を示した図である。
【図５】アナログ／デジタル変換ドライバの構成を示した図である。
【図６】検証のための観測点を挿入するための構成を示した図である。
【図７】テンプレート記述を用いたソフトウェア部品のインターフェース記述の例を示した図である。
【図８】テンプレートによるソフト部品記述を示した図である。
【図９】制御ソフトウェア開発ツールの入出力を示した図である。
【図１０】テンプレート処理部の処理内容を示した図である。
【図１１】目的とするソフトウェアの設定情報を示した図である。
【図１２】テンプレート処理部の詳細を示した図である。
【発明を実施するための形態】
【００１４】
以下本発明の実施形態について説明する。
【００１５】
図２は本発明の対象とする制御システムのひとつである自動車エンジン制御システムの構成を示すものである。車載制御装置（コントロールユニット）２０１は中央演算装置２０４（ＣＰＵ），割込み制御回路２０８，読み出し専用メモリ２０６（ＲＯＭ），揮発性読み書きメモリ２０５（ＲＡＭ），入力回路２０３，出力回路２０７，マイコン２０２，出力ポート２１１、から構成される。
【００１６】
コントロールユニット２０１には、各種センサ２１６が信号入力回路２１３を介して、アクチュエータ２１２が駆動回路２１０を介してそれぞれ接続され、コントロールユニット２０１がこれらの制御を行う。制御はＣＰＵをはじめとする構成要素から入力ポート・出力ポートのレジスタへの読み書きにより行われる。
【００１７】
車両制御の方法を記述したソフトウェアはコントロールユニット上のＲＯＭ２０６およびＲＡＭ２０５といった記憶手段に搭載され、ＣＰＵ２０４において所望の制御を行うように実行される。ここではマイコン内部にＣＰＵ，ＲＡＭ，ＲＯＭが内蔵されている例を示したが、本発明の実施はこの例に限定されるものではなく、例えばコントロールユニット上のＣＰＵ，ＲＡＭ，ＲＯＭはそれぞれ別のＩＣチップで実現しても良い。
【００１８】
本発明では、このような制御装置上に図１に示すソフトウェアを搭載しその制御を行う。制御ソフトウェア開発ツール１０２（実施例２にて詳述）によって作成される制御ソフトウェア１０１（実施例１にて詳述）は、制御演算処理を行うアプリケーション１０３とソフトウェア部品同士の接続を行う接続層１０４と基本ソフトウェア部１１４（基本ソフトウェア）から構成され、ハードウェア１０７の上に実装される。基本ソフトウェア１１４は、例えば車載機器との入出力処理等を行う。また基本ソフトウェア１１４は複数の処理部に階層化され、ソフトウェアの設計変更の影響を局所化する。本実施例では処理部を、上位ドライバ１０５，下位ドライバ１０６の２つの階層に分割した例を示すが、さらに多数の階層から構成しても良い。上位ドライバは、規格化されたインターフェースによりアプリケーション１０３の要求を受け付ける標準Ｉ／Ｆ１０８とドライバ内部の処理を行う処理本体１０９と下位ドライバの呼び出しや起動を行う処理をテンプレート記述言語により記述されたテンプレートインターフェース部（テンプレートＩ／Ｆ）１１０から構成される。下位ドライバ１０６は上位ドライバの呼び出しや起動を受け付けるテンプレートＩ／Ｆ１１１とドライバ内部の処理を行う処理本体１１２とハードウェアの駆動を行う標準Ｉ／Ｆ１１３から構成する。
【００１９】
従来のソフトウェア構成では、処理部間の結合は標準インターフェース部（標準Ｉ／Ｆ）で記述されていた。標準Ｉ／Ｆは基本ソフトウェアの一部として他社へ開示されてアクセス可能となるため、インターフェースの一部を選択的に省略したり、変更したりすることは難しい。したがって、処理部間の入出力の関係をソフトウェアの設計変更に併せて柔軟に変更することは困難であった。本発明では、処理部間の入出力の関係に、テンプレート記述を用いることでソフトウェア部品の結合方法の柔軟な選択を可能とする。
【００２０】
ここで、車載電子制御装置のハードウェアとソフトウェアのデータと処理の流れの一例を図４に示す。本構成はエンジン制御システムの基本構成の一例を示したものである。電子制御ユニット４０１は、吸入空気量を調節する機能をもつスロットルバルブの開度を測定するスロットルセンサ４０６，吸気管内の圧力測定を行う吸気管圧センサ４０７，吸入空気量の測定を行うエアフローセンサ４０８，エンジンと連動して回転するクランクシャフトの角度測定を行うクランク角センサ４０９などのセンサ類それぞれから入力したエンジンの状態に基づき、エンジン点火を制御する点火プラグ駆動パルス４１０，インジェクタのバルブ開度を制御する燃料噴射装置駆動パルス４１１を出力する。この出力信号によって、エンジンの点火タイミングと燃料の噴射量が決定される。コントロールユニット２０１の内部にはマイコンが内蔵され、その入出力は、アナログ・デジタル変換器（Ａ／Ｄ変換器４０３）とパルス信号をサンプリングするパルス入力回路４０４とを介して各センサからの入力信号を取り込み、タイマ・パルス出力回路４０５を介して点火プラグ駆動パルス４１０，燃料噴射装置駆動パルス４１１とを出力する。
【００２１】
マイコンの記憶手段に搭載される制御ソフトウェア１０１では、まず、センサ値補正処理４１２，パルス入力処理４１３を介して、物理値に対応した論理的な意味のある入力データである、スロットル開度４１４，吸気管圧４１５，吸入空気量４１６，エンジン回転位置４１７を算出する。次にこれらをもとに制御アプリケーション４１８である点火制御４１９，燃料噴射制御４２０を経て算出した出力値をパルス出力処理４２１によって、ハードウェアであるタイマ・パルス制御回路を駆動し、最終出力である点火プラグ駆動パルス４１０，燃料噴射装置駆動パルス４１１を出力する。
【００２２】
図５はＡＤ変換器４０３を介して入力値を取得するための、一般的なＡＤ変換ドライバの構成を示したものである。５０１が制御ソフトウェアであり、５１３がマイコンとその内蔵ＡＤ変換器のハードウェア，４０７が吸気管圧センサ，４０８のエアフローセンサが外界の状況を検出するためのハードウェアである。センサが検出した外界の情報はＡＤ変換装置５１４を通してマイコン内に取り込まれ、ソフトウェアに提供される。本実施例ではＡＤ変換装置５１４の内部には、５１５  ＣＨ１，５１６  ＣＨ２の２つのチャネルのＡＤ変換器が搭載されており、これらはポート５１７を介してセンサと接続する。
【００２３】
ソフトウェア５０１は、吸気管圧物理値算出アプリケーション５０２，吸気流量物理値算出アプリケーション５０３，燃料噴射量算出アプリケーション５０４の制御を行うアプリケーションソフトウェアを接続層５０９で接続する。接続層５０９にはさらにハードウェアからの入力信号が接続される。ハードウェアからの入力は、ＡＤ変換器制御ドライバ５０８によって取り込む。取り込んだ値は、信号制御部を介してチャネル毎の個別のＡＤ変換結果として分離され、これらは５０５のフィルタ処理１，５０６のフィルタ処理２が接続され、入力信号のノイズの除去や異常値の遮断などを行い、物理値算出アプリケーション５０２，５０３に提供される。
【００２４】
また、上記の燃料噴射量算出アプリケーション５０４において、制御演算のもととなる入力値５０２，５０３の測定時間誤差が、燃費効率の観点などから、制御の品質へ無視できない影響を与える。５０４のような制御演算は一定の時定数のサンプリング周期に基づく演算となっており、入力値が一定周期で取り込まれることを前提としている。ところが、制御コントローラに搭載される制御システムは、搭載されているＣＰＵの限られた計算資源をスケジューリングして使用し、各アプリケーションの優先度に応じてスケジューリングされて実行されるため、必ずしも常に所望のタイミングで処理を実行できる訳ではない。このため、システムの検証の際には当該システムでの時間誤差と制御演算出力との関係を測定・確認し、最終出力値である制御演算値が所望の精度の範囲で正しい値を出力することを確認することが必要である。
【００２５】
図３に示すのが入力処理のサンプリングタイミングの周期時間誤差（ジッタ）により値が変動する様子である。センサが３０３に示す値の変化を示した場合に、３０１に示すサンプリングタイミング１で取り込んだ場合のソフトウェアが認識する入力値が３０４であり、サンプリングタイミング２  ３０２で取り込んだ場合にソフトウェアが認識する入力値が３０５となる。サンプリングタイミングの違いによって、演算の元となる入力値は３０６に示す差分をもつこととなる。サンプリングタイミング（３０１，３０２）はシステム全体の優先度や負荷などによって変化するため、あらかじめモジュール単体で検証することは困難であり、システム統合した上で検証する必要がある。また、車載制御ソフトウェアにおいては、車載機器の制御はそれぞれが相互に関係を持っており、多くの車載機器を統合的に制御する必要がある。したがって、モジュール単体での検証はさらに困難となる。また一般的に、組み込み制御装置は汎用コンピュータのような充実したデバッグ環境が整っていないことが通常であり、また上述の通り階層間の入出力の関係は標準化されているため、従来のソフトウェア構成では検証が難しい。
【実施例１】
【００２６】
ここで、上記の周期時間誤差の測定を可能にする構成として、本発明の一実施例を図６に示す。本実施例では、基本ソフトウェアの内部に観測点を挿入することによって内部データの検証が可能となる方法を説明する。図６は入出力ソフトウェア６０１と入出力回路６０２，外部入出力デバイス６１６から構成されている。吸気管圧センサ４０７とエアフローセンサ４０８の２つの値をＡＤ変換器４０３で取り込む際のタイミングの周期時間誤差はＡＤ変換器ドライバで検出可能であるため、ＡＤ信号群制御部６０３との接続部６１５にて測定タイミング毎にタイミング出力信号部１  ６０８，タイミング信号出力部２  ６０９に通知する。ここで接続部とは、各ソフトウェア部品に存在し、外部の部品との接続を行う役割を持つ部分のことを表す。タイミング出力信号部から、デジタル出力部１  ６１０，デジタル出力部２  ６１１を介してデジタル信号出力回路６１２を介して観測端子１  ６１３，観測端子２  ６１４の出力信号を比較することによって検証可能となる。
【００２７】
図１にて説明を行ったテンプレート記述を用いたソフトウェア部品のインターフェース記述の例を図７に示す。７０１，７０２，７０３はＣ言語のコメント行である。７０３の行中＄！｛Ｐｏｒｔ｝という記述がテンプレートであり、この文字列がテンプレートコンパイラによる文字列置換の対象となる。同様に７０５，７０７，７０８の＄！｛ＢＩＴ｝の記述も同様である。ここで、テンプレートコンパイラとはコード生成手段１１５の一部であり、その処理の流れ（１１０４，１１０５，１１０６）は図１０にて後述する。本実施例のように、テンプレート記述を、上述通り用いることで、接続部を経由するデータの外部送信，受け渡しタイミング信号の出力，デバッグ装置向けのシリアル通信，データの記憶，デバッグ用の擬似信号の入力など様々な用途ごとの使い分けが容易となり、ソフトウェアの検証，性能解析に役立てることができる。本実施例によれば、ソフトウェア部品の処理本体をブラックボックス化したままでも、テンプレートＩ／Ｆを変更するだけでソフトウェアのデバッグが可能となる。
【００２８】
なお、図８は同様にＣ言語の実体の記述の例である。図７と同様に８０３，８０４，８０６，８１１，８１２にテンプレート記述（＄！｛Ｐｏｒｔ｝，＄！｛Ｇｒｏｕｐ｝）を記述する。
【実施例２】
【００２９】
図９は、上述のテンプレート記述によるソフトウェア部品を組み込み制御コントローラに搭載する形態にするための１０２に示した制御ソフトウェア作成装置を用いたソフトウェア開発の実施例を示したものである。１０２はユーザからの入力である設定情報１００１とソフトウェア部品１００２を入力する。設定情報１００１は通常パラメータ設定を支援するツールから出力されるデータであり、ＸＭＬ（eXtensible Markup Language）フォーマットで記述するのが典型的な例である。この設定情報１００１とは、具体的には吸気管圧センサ，水温センサ，吸気温度センサ，スロットルセンサなど、複数のセンサの内から使用するセンサのドライバをソフトウェア設計のために選択した結果などが例として挙げられる。後に設定情報の記載例について説明を行う。なお、ソフトウェア部品１００２は開発部署の設計資産として蓄積されているのが通例である。また、ソフトウェア部品１００２はベロシティテンプレート言語（Velocity Template Language（非特許文献１）で記述することが考えられるが、文字列置換などのテンプレート言語特有の機能を使う必要が無ければＣ言語などの実装フェーズで用いる言語を用いることも可能である。
【００３０】
１００３テンプレート処理部では内部的あるいは外部コマンドとしてベロシティコンパイラを用いて、開発者の設定した各種パラメータを適宜ソフトウェアへ組み込む。ここでいう各種パラメータとは、ブレーキの利き具合やエンジンの点火のタイミングなど、車両制御に関わる各種設定値を含む。こうして得られたＣ言語によるソフトウェア部品１００４は、１００５コンパイラ処理部によりオブジェクト形式のソフトウェア部品１００６へ変換され、さらにリンカ処理部１００７によって、実際の車載電子制御装置へ書き込む制御ソフトウェアの実装ファイル１００８を得る。すなわち本実施例によれば、ユーザの設定した情報から、あらかじめ開発されたソフトウェア部品適宜選択、結合して制御ソフトウェアの作成を行うことができる。
【００３１】
図１０は図９のテンプレート処理部１００３の詳細を示したものである。図１の設定情報入力手段１１７を介して設定情報１００１を入力し、１１０３で読み込み解析する。この設定情報は上述の通りＸＭＬで記述することが考えられ、一般のＸＭＬパーザ（ＪＡＸＰなど）を用いる（非特許文献２）。次に設定情報に基づき出力テンプレートをソフトウェア部品ＤＢ１１８から入力する。ソフトウェア部品ＤＢ１１８の実体は一般のデータベースでも良いし、Ｗｉｎｄｏｗｓ（登録商標）などのパーソナルコンピュータ搭載のオペレーティングシステム上のファイルシステムでも良い。次に、部品選択手段１１６にて、読み込んだ設定情報１１０３から出力に用いるテンプレートを選択し、コード生成手段１１５にて、出力情報を設定（１１０５）し、最後に出力処理（１１０６）を行い、ソフトウェア部品１００４にあたるＣ言語ファイル１１０７，Ｃ言語ヘッダファイル１１０８を得る。
【００３２】
図１１は設定情報の一例である。この例では３点（１２０１，１２０５，１２０６）のＩＯ処理ソフトウェアのための設定情報が記載されており、１２０１で、吸入空気量センサが、アナログ−デジタル変換器（ＡＤＣ）１２０２のインターフェースを介し、ポートグループＰＡ１２０３，ポート番号ＰＡ０３１２０４を介して入力することを定義している。
【００３３】
なお、図１２は図１０に示したテンプレート処理部１００３の実装をＪａｖａ（登録商標）言語で行った例を示したものであり、１３０１で設定情報入力１１０３を行い、１３０２で部品選択と読み込み１１０４を行い、１３０３で設定情報の解析と出力情報の設定１１０５を行い、１３０４で出力処理１１０６を行う。一連の処理の結果として、Ｃ言語ファイル１１０７、Ｃ言語ヘッダファイル１１０８が出力される。
【００３４】
この例では、図８の変数“＄｛Ｐｏｒｔ｝”（８０３，８１１）に対応する情報として、図１２“ＰＡ０３”（１２０４）を図１２（１３０３）で対応付けることにより、図８の“＄｛Ｐｏｒｔ｝”を“ＰＡ０３”で文字列置換されたものが出力として得られる。図８の変数“＄｛Ｇｒｏｕｐ｝”も同様にして、図１１の“ＰＡ”（１２０３）に文字列置換されることで、目的とするＣ言語のソースファイルとして出力される。
【００３５】
このように本実施例によれば、ユーザの入力する設定情報から基本ソフトウェアのテンプレートＩ／Ｆのみを書き換えることによって、階層間の入出力の関係を自動的に選択でき、さらにはソースコード本体の書き換えを抑えながら、保守，検証の手段を提供することができる。したがって、ソースコード本体をブラックボックス化したままソフトウェア部品を開示することが容易となる。
【００３６】
本実施例における設定情報１００１の入力内容は、一例として上述のようなセンサの選択や観測点挿入の例を挙げているが、この例に限られるものでなく、ソフトウェア部品の結合に関して有用な情報であれば何でも良い。なお、他の設定情報の例として、顧客や分業を行う他社から要求されるコンフォーマンスクラス情報を設定情報１００１として入力してもよい。ここでいうコンフォーマンスクラスとは、ソフトウェアの標準化において発行されている標準仕様のなかで定義される標準化への準拠度合いを表す。コンフォーマンスクラスによって、分業開発を行う各社から開示されるソフトウェア資産の内容や、ブラックボックス化されるソフトウェア資産の規模が異なる。標準化への準拠度が高くなれば、各社から開示されるソフトウェア資産は多くなるが、性能検証・保守等の観点からブラックボックス化したソフトウェア内の中間データ，タイミングの計測が重要となる。また、オーバーヘッド，ソフトウェア性能の観点でも、標準化が進んだ場合は階層間の結合、ソフトウェア部品の配置を柔軟に行うことは困難となる。
【００３７】
したがって、標準化への準拠度に応じて、分業開発したソフトウェアに各社それぞれのノウハウをブラックボックス化して盛り込むことは、各社の利益・技術確保の点から非常に重要となる。本実施例においてコンフォーマンスクラスに応じてテンプレート記述を変更してソフトウェア階層間，ソフトウェア部品間の結合方法を選択することで、標準化への準拠度合いによって規模が可変するブラックボックス部分に適切な観測点を挿入することができる点、柔軟にソフトウェア部品の一体化を行うことができる点などから、分業によるソフトウェア開発の効果を高めることができる。
【００３８】
本発明によれば、基本ソフトウェア内の階層間の入出力の関係をテンプレート記述によって選択することで、柔軟な設計変更を可能とすることができる。また、ソフトウェア資産をシステムに統合する時に、個別ソフトウェアモジュールの詳細設計であるソースコードの開示を抑えながら、検証，性能計測のための情報の出力を柔軟に切り替えることが可能となるため、システム統合時の保守，検証，性能計測が容易となり、分業体制によるソフトウェア開発における検証工数を削減することが可能となる。したがって、ソフトウェアの部品化，開発済みソフトウェアの再利用，複数の事業主体による協業の促進を図ることができる。
【００３９】
また部品の結合方法は、部品間で使用する機能やその多寡によって、Ｃ言語の関数呼び出しとして実装する、あるいは処理本体を呼び出し元に埋め込み実装する、不要インターフェースが残るなど、実装方法により性能，プログラムサイズなどに差異があり、開発者の知見が大きく反映されてしまう。しかし、本実施例のように、制御ソフトウェアを支援する開発ツールを用いてテンプレートＩ／Ｆのみを書き換えることによって、効果的にソフトウェア部品の結合方法を選択できるので、開発者の知見が制御ソフトウェアの完成度に与える影響を抑えることができる。
【００４０】
また近年、安全性，燃費性能，快適性などの向上の観点から電子制御が急速に進んでいるため、車両制御ソフトウェアの開発費は高くなる傾向にある。これは各事業主体が基本ソフトウェア部分までも各々のソフトウェア資産として独自開発してきたことが一因でもあるが、本発明によれば分業体制の促進により標準化が進み、開発効率が高まる他、搭載車両に合わせた仕様変更なども抑えることができ、ひいては自動車の生産コストの低減に貢献できる。
【符号の説明】
【００４１】
１０１，５１０  制御ソフトウェア
１０２  制御ソフトウェア開発ツール
１０８，１１３  標準インターフェース
１１０，１１１  テンプレートインターフェース
１１５  コード生成手段
１１６  部品選択手段
１１７  設定情報入力手段
１１８  ソフトウェア部品ＤＢ
２０１  車載制御装置
５１１  入出力信号処理部
５１２  入出力制御部
５１３  ハードウェア
６０１  入出力ソフトウェア
６０２  入出力回路
６１５  接続部
６１６  外部入出力デバイス
【図１】
2010237895.tif 000003
【図２】
2010237895.tif 000004
【図３】
2010237895.tif 000005
【図４】
2010237895.tif 000006
【図５】
2010237895.tif 000007
【図６】
2010237895.tif 000008
【図７】
2010237895.tif 000009
【図８】
2010237895.tif 000010
【図９】
2010237895.tif 000011
【図１０】
2010237895.tif 000012
【図１１】
2010237895.tif 000013
【図１２】
2010237895.tif 000014