(57)【特許請求の範囲】
【請求項１】
車両に搭載され、複数の通信バスを介して互いにデータ通信を行う複数のＥＣＵのいずれかにそれぞれ搭載される複数のＣＰＵのうち１つについて、当該１つのＣＰＵ（以下、第１ＣＰＵという）のソフトウェアプラットフォームと前記第１ＣＰＵのアプリケーションとをコンパイルおよびリンクすることで当該第１ＣＰＵの作動を実現するためのオブジェクトコードを生成する工程、において用いられる、当該第１ＣＰＵについてのコンフィギュレーションコードであって、前記第１ＣＰＵが中継する通信データの情報を含むとともに前記ソフトウェアプラットフォームを利用して前記通信データの送信または受信を実現するためのプログラムを含むコンフィギュレーションコード、を生成するコンフィギュレーションコード生成装置であって、
記憶媒体と、
演算回路と、を備え、
演算回路は：
前記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データのそれぞれについての発信元の送信アプリケーションと宛先の受信アプリケーションとの対応関係を示すアプリケーション設計情報テーブル、の入力を受け付けて前記記憶媒体に記録する第１記録手段と、
前記複数のＣＰＵのそれぞれが前記複数のＥＣＵのうちどのＥＣＵに搭載されているか、および、前記複数のＣＰＵのそれぞれが前記複数の通信バスのうちどの通信バスに接続されているか、および、前記複数のＣＰＵのそれぞれが前記複数のアプリケーションのうちいずれを実行するか、についての対応関係を示すシステム設計情報テーブル、の入力を受け付けて前記記憶媒体に記録する第２記録手段と、
前記第１ＣＰＵが中継する通信データを特定する関連性判定データ、を前記第１記録手段および前記第２記録手段が記録した情報に基づいて作成して前記記憶媒体に記録する関連性記録手段と、
前記第１記録手段、前記第２記録手段、および前記関連性記録手段が記録した情報に基づいて、前記コンフィギュレーションコードを生成して前記記憶媒体に記録するコンフィギュレーションコード生成記録手段と、を有し、
前記関連性記録手段は、前記アプリケーション設計情報テーブルに基づいて、前記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データのそれぞれについての発信元の送信アプリケーションおよび宛先の受信アプリケーションを特定する第１特定手段と、
前記第１特定手段の特定結果を前記システム設計情報テーブルに適用することで、前記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データの通信経路が、あらかじめ定められた複数の経路パターンのいずれに該当するかを特定する第２特定手段と、
前記第２特定手段の特定結果に基づいて、前記該当する経路パターンがゲートウェイのＣＰＵによって中継される経路パターンであれば、前記第１ＣＰＵが前記通信経路でゲートウェイになっているか否かに応じて、前記第１ＣＰＵが前記通信データの中継を行うか否かを特定し、その特定結果を前記関連性判定データとして前記記憶媒体に記録する第３特定手段と、を有することを特徴とするコンフィギュレーションコード生成装置。
【請求項２】
車両に搭載され、複数の通信バスを介して互いにデータ通信を行う複数のＥＣＵのいずれかにそれぞれ搭載される複数のＣＰＵのうち１つについて、当該１つのＣＰＵ（以下、第１ＣＰＵという）のソフトウェアプラットフォームと前記第１ＣＰＵのアプリケーションとをコンパイルおよびリンクすることで前記第１ＣＰＵの作動を実現するためのオブジェクトコードを生成する工程、において用いられる、前記第１ＣＰＵについてのコンフィギュレーションコードであって、前記第１ＣＰＵが中継する通信データの情報を含むとともに前記ソフトウェアプラットフォームを利用して前記通信データの送信または受信を実現するためのプログラムを含むコンフィギュレーションコード、を生成するコンフィギュレーションコード生成装置に用いるプログラムであって、
複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データのそれぞれについての発信元の送信アプリケーションと宛先の受信アプリケーションとの対応関係を示すアプリケーション設計情報テーブル、の入力を受け付けて記憶媒体に記録する第１記録手段、
前記複数のＣＰＵのそれぞれが前記複数のＥＣＵのうちどのＥＣＵに搭載されているか、および、前記複数のＣＰＵのそれぞれが前記複数の通信バスのうちどの通信バスに接続されているか、および、前記複数のＣＰＵのそれぞれが前記複数のアプリケーションのうちいずれを実行するか、についての対応関係を示すシステム設計情報テーブル、の入力を受け付けて前記記憶媒体に記録する第２記録手段、
前記第１ＣＰＵが中継する通信データを特定する関連性判定データ、を前記第１記録手段および前記第２記録手段が記録した情報に基づいて作成して前記記憶媒体に記録する関連性記録手段、および
前記第１記録手段、前記第２記録手段、および前記関連性記録手段が記録した情報に基づいて、前記コンフィギュレーションコードを生成して前記記憶媒体に記録するコンフィギュレーションコード生成記録手段、としてコンピュータを機能させ、
前記関連性記録手段は、前記アプリケーション設計情報テーブルに基づいて、前記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データのそれぞれについての発信元の送信アプリケーションおよび宛先の受信アプリケーションを特定する第１特定手段と、
前記第１特定手段の特定結果を前記システム設計情報テーブルに適用することで、前記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データの通信経路が、あらかじめ定められた複数の経路パターンのいずれに該当するかを特定する第２特定手段と、
前記第２特定手段の特定結果に基づいて、前記該当する経路パターンがゲートウェイのＣＰＵによって中継される経路パターンであれば、前記第１ＣＰＵが前記通信経路でゲートウェイになっているか否かに応じて、前記第１ＣＰＵが前記通信データの中継を行うか否かを特定し、その特定結果を前記関連性判定データとして前記記憶媒体に記録する第３特定手段と、を有することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンフィギュレーションコード生成装置およびコンフィギュレーションコード生成装置用プログラムに関する。
【背景技術】
【０００２】
従来、車両に搭載され、当該車両内の他のＥＣＵとデータ通信を行うＥＣＵの開発において、当該ＥＣＵが搭載するＣＰＵで実行させるプログラムを、ソフトウェアプラットフォーム（以下、ソフトウェアＰＦという）とアプリケーションに分けて作成する方法が採用されている（例えば、特許文献１参照）。
【０００３】
ソフトウェアＰＦは、当該ＣＰＵを搭載するＥＣＵのハードウェアを直接駆動するためのプログラム群である。したがって、ソフトウェアＰＦの構成は、当該ＥＣＵのハードウェア構成に強く依存している。ソフトウェアＰＦの例としては、ＯＳ（例えばＯＳＥＫ−ＯＳ（登録商標））、デバイスドライバがある。
【０００４】
アプリケーションは、ソフトウェアＰＦの提供する機能を利用することで、当該ＣＰＵを搭載するＥＣＵのハードウェアを駆動するプログラム群である。アプリケーションとしては、例えば、当該ＥＣＵがエンジンＥＣＵであれば、エンジン点火タイミングの計算のために必要な諸量（アクセル開度、エンジン回転速等）を他のＥＣＵ（あるいは同一ＥＣＵ中の他のＣＰＵ）から受信し、それら受信した情報から点火タイミングを算出し、算出した点火タイミングが実現するよう、インジェクタを制御する処理を実現するためのプログラムがある。
【０００５】
ソフトウェアＰＦが提供する機能のアプリケーションによる利用は、例えば、ソフトウェアＰＦが、ハードウェアを用いた作動（例えば、アクチュエータへの制御信号の出力、センサからの検出信号の取得、他のＥＣＵとの間の信号の送受信）を実行するためのアプリケーションインターフェース（以下ＡＰＩという）を提供し、アプリケーションが、必要に応じてそれらＡＰＩを呼び出すことで実現する。
【０００６】
異なるＥＣＵに搭載されるソフトウェアＰＦは、共通のＡＰＩをアプリケーションに提供するようになっていることが多い。したがって、アプリケーションの作成においては、ＥＣＵのハードウェア構成を意識してコーディングする必要がなくなる。
【０００７】
また、図２のソフトウェア階層図に示すように、ソフトウェアＰＦ１の一部として、あるいは、ソフトウェアＰＦ１およびコンフィギュレーションコード２とは異なるものとして、コンフィギュレーションコード２を更に開発する方法が採用されている。
【０００８】
コンフィギュレーションコードは、アプリケーションが扱う通信用のデータの詳細情報を含んでいる。アプリケーションが扱う通信用のデータとは、当該アプリケーションが、他のＣＰＵで実行される他のアプリケーションと受け渡しをするデータをいう。通信相手のアプリケーションが同じＥＣＵ内の他のＣＰＵで実行される場合には、当該通信データはＣＰＵ間通信のデータとなる。通信相手のアプリケーションが他のＥＣＵ内のＣＰＵで実行される場合には、当該通信データはＥＣＵ間通信のデータとなる。
【０００９】
また、コンフィギュレーションコードは、ソフトウェアＰＦを利用して当該通信データの送信または受信を実現するためのプログラムを含む。ソフトウェアＰＦを利用して通信データの送信または受信を実現するためのプログラムとは、具体的には、データの送受信用の関数プログラム（以下、通信データ関数という）である。これらの通信データ関数は、ソフトウェアＰＦの提供するＡＰＩを利用している。そして、アプリケーションは、これらデータ送受信用の通信データ関数を呼び出すことで、データの送受信を実現するように記述されている。
【００１０】
あるＣＰＵにおけるコンフィギュレーションコードは、当該ＣＰＵで実行される全アプリケーションが扱う通信データの種類毎に１つのデータ送受信用関数を有するように構成されるのが通常である。
【００１１】
あるＣＰＵ用のプログラムの実行イメージ（すなわちオブジェクトコード）は、図３に示すように、当該ＣＰＵ用のソフトウェアＰＦ、コンフィギュレーションコード、アプリケーションをコンパイルしてリンクすることで作成される。
【特許文献１】特開２０００−３３０７７５号公報
【非特許文献１】“Specification of RTE Software”、[online]、平成８年５月５日、AUTOSAR GbR、インターネット<URL:http://www.autosar.org/download/R2.0/AUTOSAR SWS_RTE.pdf>
【発明の開示】
【発明が解決しようとする課題】
【００１２】
図４に、コンフィギュレーションコードの生成の方法の一案を概略的に示す。コンフィギュレーションコード８は、通常のコンピュータ５０において実行されるプログラムであるコンフィグツール７の実行によって作成される。
【００１３】
図５に、コンフィグツール７を用いたコンフィギュレーションコードの作成の手順の概要をフローチャートで示す。この図に示すように、ユーザは、アプリケーション仕様４に基づいてアプリケーション設計情報テーブルを作成してコンフィグツール７に入力し（ステップ１１０）、システム仕様５に基づいてシステム設計情報テーブルを作成してコンフィグツール７に入力し（ステップ１２０）、通信仕様６に基づいて通信リソース設計情報テーブルを作成してコンフィグツール７に入力する（ステップ１３０）。そして、ユーザがコンフィグツール７に対して所定の実行指令を行うことで、コンフィグツール７がこれら設計情報テーブルからコンフィギュレーションコードを生成させる（ステップ１４０）。
【００１４】
アプリケーション設計情報テーブルは、アプリケーションが送受信する複数種類の通信データ毎に、当該種類の通信データの発信元である送信アプリケーションと当該種類の通信データの宛先である受信アプリケーションとの対応関係を示すデータである。
【００１５】
システム設計情報テーブルは、車両内に搭載される複数のＥＣＵ中の複数のＣＰＵ毎に、当該ＣＰＵを搭載するＥＣＵ、当該ＣＰＵに接続される通信バス、および、当該ＣＰＵが実行するアプリケーションの対応関係を示すデータである。
【００１６】
通信リソース設計情報テーブルは、１つのＣＰＵにつき１つ作成されるようになっている。各通信リソース設計情報テーブルは、概要データ、関連性判定データ、詳細データ、およびリソースマッピングデータを有している。概要データは、複数種類の通信データ毎に、当該種類の通信データの発信元である送信ＣＰＵと当該種類の通信データの宛先である受信ＣＰＵとの対応関係を示すデータである。関連性判定データは、当該ＣＰＵが当該通信データの送受信に関与するか否かを示すデータである。詳細データは、当該通信データの詳細（例えば、送信周期）を示すデータである。リソースマッピングデータは、当該通信データの、プラットフォーム側から参照されるときの名称と、アプリケーション側から参照されるときの名称と、の対応関係を示すデータである。
【００１７】
ユーザは、ステップ１１０、１２０、１３０において、コンフィグツール７に対して手作業で各種情報を入力することで、アプリケーション設計情報テーブルおよびシステム設計情報テーブルの作成を完了する。図１３に、ステップ１３０の作業の手順をより詳細に示す。この図に示す通り、ステップ１３０においては、まず通信リソース設計情報テーブル中の概要データをユーザが手入力で設定し（ステップ４１０）、続いてリソースマッピングデータをユーザが手入力で設定し（ステップ４２０）、続いて関連性判定データをユーザが手入力で設定し（ステップ４２０）、最後に、詳細データを、ユーザが手入力で設定する（ステップ４３０）。なお、ステップ４１０〜４４０における手入力においては、ユーザは通信仕様６のデータを参照する。
【００１８】
以上のような手順で、アプリケーション設計情報テーブル、システム設計情報テーブル、通信リソース設計情報テーブルが作成され、それらのテーブルに基づいてコンフィギュレーションコードが自動生成される。コンフィギュレーションコード（ＲＴＥ）の標準仕様については、例えば非特許文献１に記載されている。
【００１９】
しかし、アプリケーション設計情報テーブル、システム設計情報テーブル、通信リソース設計情報テーブルの作成は、自動化されていないので、ユーザの負担が大きい。本発明は上記の点に鑑み、車載ＥＣＵに搭載されるＣＰＵのためのコンフィギュレーションコードの開発において、コンフィギュレーションコードの作成に必要な情報のユーザによる入力作業を軽減することを目的とする。
【課題を解決するための手段】
【００２０】
本発明者は、アプリケーション設計情報テーブルおよび通信リソース設計情報テーブルの内容が決まれば、関連性判定データの内容を決定するための情報が揃うことに着目した。
【００２１】
上記目的を達成するための本発明の特徴は、車両に搭載され、複数の通信バスを介して互いにデータ通信を行う複数のＥＣＵのいずれかにそれぞれ搭載される複数のＣＰＵのうち１つについて、当該１つのＣＰＵＣＰＵ（以下、第１ＣＰＵという）のソフトウェアプラットフォームと前記第１ＣＰＵのアプリケーションとをコンパイルおよびリンクすることで当該第１ＣＰＵの作動を実現するためのオブジェクトコードを生成する工程、において用いられる、当該第１ＣＰＵについてのコンフィギュレーションコードであって、前記第１ＣＰＵが中継する通信データの情報を含むとともに前記ソフトウェアプラットフォームを利用して前記通信データの送信または受信を実現するためのプログラムを含むコンフィギュレーションコード、を生成するコンフィギュレーションコード生成装置についてのものである。
【００２２】
このコンフィギュレーションコード生成装置は、記憶媒体と、演算回路と、を備えておいる。そして、演算回路はアプリケーション設計情報テーブルの入力を受け付けて上記記憶媒体に記録する第１記録手段と、システム設計情報テーブルの入力を受け付けて上記記憶媒体に記録する第２記録手段と、を備えている。
【００２３】
ここで、アプリケーション設計情報テーブルは、上記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データのそれぞれについての発信元の送信アプリケーションと宛先の受信アプリケーションとの対応関係を示すデータである。
【００２４】
また、システム設計情報テーブルは、上記複数のＣＰＵのそれぞれが上記複数のＥＣＵのうちどのＥＣＵに搭載されているか、および、上記複数のＣＰＵのそれぞれが上記複数の通信バスのうちどの通信バスに接続されているか、および、上記複数のＣＰＵのそれぞれが上記複数のアプリケーションのうちいずれを実行するか、についての対応関係を示すデータである。
【００２５】
また、演算回路は、第１ＣＰＵを対象とする関連性判定データを、上記第１および第２記録手段が記録した情報に基づいて作成して上記記憶媒体に記録する関連性記録手段を有している。当該関連性判定データは、対象とする第１ＣＰＵが通信に関与する通信データを特定するようになっている。
【００２６】
さらに、演算回路は、第１および第２記録手段、および関連性記録手段が記録した情報に基づいて、上記コンフィギュレーションコードを生成して上記記憶媒体に記録するコンフィギュレーションコード生成記録手段を有している。
【００２７】
このように、コンフィギュレーションコード生成装置は、コンフィギュレーションコードの生成のために必要な関連性判定データを自動的に生成・記録する。その生成の具体的手段として、関連性記録手段は、下記第１〜第３特定手段を有する。
【００２８】
第１特定手段は、上記アプリケーション設計情報テーブルに基づいて、上記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データのそれぞれについての発信元の送信アプリケーションおよび宛先の受信アプリケーションを特定する。
【００２９】
第２特定手段は、更に上記第１特定手段の特定結果を上記システム設計情報テーブルに適用することで、上記複数のＣＰＵのいずれかにおいてそれぞれ実行される複数のアプリケーションが送信する複数種類の通信データの通信経路が、あらかじめ定められた複数の経路パターンのいずれに該当するかを特定する。
【００３０】
第３特定手段は、上記第２特定手段の特定結果に基づいて、前記該当する経路パターンがゲートウェイのＣＰＵによって中継される経路パターンであれば、前記第１ＣＰＵが前記通信経路でゲートウェイになっているか否かに応じて、前記第１ＣＰＵが前記通信データの中継を行うか否かを特定し、その特定結果を上記複数の関連性判定データとして上記記憶媒体に記録する。
【００３１】
このように、各通信データについて、アプリケーション設計情報テーブルの送信アプリケーション−受信アプリケーションの関係、およびシステム設計情報テーブルのシステム構成から、当該通信データの経路を特定し、さらにその経路パターンを特定し、当該経路パターンに対応付けられた方法で、通信データの配送にどのＣＰＵが関与するかの情報、すなわち関連性判定データを自動的に特定することができる。
【００３２】
また、このようにして作成される各ＣＰＵ用のコンフィギュレーションコードには、関連性判定データの内容が反映されるので、当該ＣＰＵが送信も受信も行わず、かつゲートウェイ（すなわち中継役）にもならないような通信データ、すなわち、当該ＣＰＵが配送に関与しないデータについては、そのデータの詳細情報を含まないように生成され、かつ、そのデータを扱う通信データ関数を含まないように生成される。したがって、生成される実行イメージのサイズが低減され、その結果、ＥＣＵのＲＯＭ容量をより効率的に利用することができる。
【００３３】
また、本発明のコンフィギュレーションコード生成装置の特徴は、プログラムとして捉えることもできる。
【発明を実施するための最良の形態】
【００３４】
以下、本発明の一実施形態について説明する。図１に、通信システム６０において、複数のＥＣＵ（ＥＣＵ−Ｅ０１、ＥＣＵ−Ｅ０２、ＥＣＵ−Ｅ０３）のそれぞれが車両内の通信バスＢ１、Ｂ２のいずれかまたは両方に接続されている状態の例を示す。本実施形態は、これら複数のＥＣＵのそれぞれに搭載されるＣＰＵ（ＣＰＵ−Ｃ０１、ＣＰＵ−Ｃ０２、ＣＰＵ−Ｃ０３、ＣＰＵ−Ｃ０４）に実行させるプログラムの作成の手順およびその作成の手順において用いる装置について説明する。
【００３５】
図２に、ＣＰＵ−Ｃ０１、ＣＰＵ−Ｃ０２、ＣＰＵ−Ｃ０３、ＣＰＵ−Ｃ０４のそれぞれにおいて実行されるプログラム群のソフトウェア階層構造を示す。各ＣＰＵが実行するプログラムは、ソフトウェアプラットフォーム（以下、ソフトウェアＰＦという）１、コンフィギュレーションコード（図中では、コンフィグコードと記す）２、およびアプリケーション３に分けられる。なお、コンフィギュレーションコード２は、ソフトウェアＰＦ１の一部であると捉えてもよいし、ソフトウェアＰＦ１とは別個のものと捉えてもよい。
【００３６】
ソフトウェアＰＦは、当該ＣＰＵを搭載するＥＣＵのハードウェアを直接駆動するためのプログラム群である。したがって、ソフトウェアＰＦの構成は、当該ＥＣＵのハードウェア構成に強く依存している。ソフトウェアＰＦの例としては、ＯＳ（例えばＯＳＥＫ−ＯＳ（登録商標））、デバイスドライバがある。
【００３７】
アプリケーションは、ソフトウェアＰＦの提供する機能を利用することで、当該ＣＰＵを搭載するＥＣＵのハードウェアを駆動するプログラム群である。アプリケーションとしては、例えば、当該ＥＣＵがエンジンＥＣＵであれば、エンジン点火タイミングの計算のために必要な諸量（アクセル開度、エンジン回転速等）を他のＥＣＵ（あるいは同一ＥＣＵ中の他のＣＰＵ）から受信し、それら受信した情報から点火タイミングを算出し、算出した点火タイミングが実現するよう、インジェクタを制御する処理を実現するためのプログラムがある。
【００３８】
ソフトウェアＰＦが提供する機能のアプリケーションによる利用は、例えば、ソフトウェアＰＦが、ハードウェアを用いた作動（例えば、アクチュエータへの制御信号の出力、センサからの検出信号の取得、他のＥＣＵとの間の信号の送受信）を実行するためのアプリケーションインターフェース（以下ＡＰＩという）を提供し、アプリケーションが、必要に応じてそれらＡＰＩを呼び出すことで実現する。
【００３９】
異なるＥＣＵに搭載されるソフトウェアＰＦは、共通のＡＰＩをアプリケーションに提供するようになっていることが多い。したがって、アプリケーションの作成においては、ＥＣＵのハードウェア構成を意識してコーディングする必要がなくなる。
【００４０】
コンフィギュレーションコードは、アプリケーションが扱う通信データの詳細情報（例えば、送受信周期、初期値、フェイル値）を含んでいる。アプリケーションが扱う通信データとは、当該アプリケーションが、他のＣＰＵで実行される他のアプリケーションと受け渡しをするデータをいう。通信相手のアプリケーションが同じＥＣＵ内の他のＣＰＵで実行される場合には、当該データはＣＰＵ間通信のデータとなる。通信相手のアプリケーションが他のＥＣＵ内のＣＰＵで実行される場合には、当該通信データはＥＣＵ間通信のデータとなる。また、コンフィギュレーションコードは、ソフトウェアＰＦを利用して当該通信データの送信または受信を実現するためのプログラムを含む。ソフトウェアＰＦを利用して通信データの送信または受信を実現するためのプログラムとは、具体的には、通信データの送受信用の関数プログラム（以下、通信データ関数という）である。これらの通信データ関数は、ソフトウェアＰＦの提供するＡＰＩを利用している。そして、アプリケーションは、これらデータ送受信用の通信データ関数を呼び出すことで、データの送受信を実現するように記述されている。
【００４１】
あるＣＰＵにおけるコンフィギュレーションコードは、当該ＣＰＵで実行される全アプリケーションが扱う通信データの種類毎に１つのデータ送受信用関数を有するようになっている。
【００４２】
あるＣＰＵ用のプログラムの実行イメージ（すなわちオブジェクトコード）は、図３に示すように、当該ＣＰＵ用のソフトウェアＰＦ、コンフィギュレーションコード、アプリケーションをコンパイルしてリンク（本明細書においては、スタティックリンクをいう）することで作成される。
【００４３】
図４に、コンフィギュレーションコードの生成の方法を概略的に示す。コンフィギュレーションコード８は、通常のコンピュータ（コンフィギュレーションコード生成装置の一例に相当する）５０において実行されるプログラムであるコンフィグツール７の処理によって作成される。
【００４４】
コンピュータ５０は、図示しない演算回路（すなわちＣＰＵ）、ＲＡＭ、ＲＯＭ、ハードディスクドライブ（記憶媒体の一例に相当する）、操作装置（キーボード、マウス等）を備えている。当該演算回路は、ＲＡＭまたはハードディスクドライブに記憶されているコンフィグツール７を読み出して実行する。演算回路がコンフィグツール７を実行しているとき、コンフィギュレーションコード８の作成者であるユーザは、アプリケーション仕様４、システム仕様５、通信仕様６等の情報を参照することで、コンフィギュレーションコードの作成に必要な情報を構成し、それら構成した情報を、操作装置を操作することで、演算回路に入力する。演算回路は、これら入力された情報に基づいて、コンフィギュレーションコード８を生成し、ハードディスクドライブに記録する。なお、図３で示した、コンパイル、リンク、実行イメージの生成の処理については、コンピュータ５０の演算回路が行うようになっていてもよいし、コンピュータ５０以外の装置が行うようになっていてもよい。
【００４５】
図５に、コンフィグツール７を用いたコンフィギュレーションコードの作成の手順の概要をフローチャートで示す。この図に示すように、ユーザは、アプリケーション仕様４に基づいて図６に例示するようなアプリケーション設計情報テーブルを作成してコンフィグツール７に入力し（ステップ１１０）、システム仕様５に基づいて図７に例示するようなシステム設計情報テーブルを作成してコンフィグツール７に入力し（ステップ１２０）、通信仕様６に基づいて図８に例示するような通信リソース設計情報テーブルを作成してコンフィグツール７に入力する（ステップ１３０）。そして、ユーザがコンフィグツール７に対して所定の実行指令を行うことで、コンフィグツール７がこれら設計情報テーブルからコンフィギュレーションコードを生成させる（ステップ１４０）。
【００４６】
アプリケーション設計情報テーブルは、図６に示すように、当該アプリケーションが扱う通信データの種類毎のレコードから成り、各レコードは、対象となるデータ種別のアプリケーション名（すなわち、当該通信データをアプリケーションから参照するときの名称）、当該種別の通信データの発信元である送信アプリケーションの名称、当該種類の通信データの宛先である受信アプリケーションの名称、および当該種別の通信データの詳細（初期値、フェイル値等）を含む。したがって、アプリケーション設計情報テーブルを参照することで、複数種類の通信データ毎に、当該種類の通信データの発信元である送信アプリケーションと当該種類の通信データの宛先である受信アプリケーションとの対応関係がわかる。なお、アプリケーション設計情報テーブルは、通信システム６０において実行される複数のアプリケーションについてまとめて１つ作成される。
【００４７】
システム設計情報テーブルは、図７に示すように、通信システム６０において用いられる通信バス毎にレコードを有し、レコードは、対象となる通信バスの名称、当該通信バスで用いられるプロトコル名、および当該通信バスに接続されるＣＰＵリストが記録されている。また、ＣＰＵリスト中には、当該通信バスに接続されるＣＰＵのそれぞれについて、当該ＣＰＵにおいて実行されるアプリケーション、当該ＣＰＵの搭載先のＥＣＵの情報が記録されている。したがって、通信リソース設計情報テーブルを参照することで、複数のＣＰＵ毎に、当該ＣＰＵを搭載するＥＣＵ、当該ＣＰＵに接続される通信バス、および、当該ＣＰＵが実行するアプリケーションがわかる。
【００４８】
図１に示した通信システム６０においては、図７に示すように、ＣＰＵ−Ｃ０１は、アプリケーションＡ０１を実行すると共にＥＣＵ−Ｅ０１に搭載されており、ＣＰＵ−Ｃ０２は、アプリケーションＡ０２を実行すると共にＥＣＵ−Ｅ０１に搭載されており、ＣＰＵ−Ｃ０３は、アプリケーションＡ０３を実行すると共にＥＣＵ−Ｅ０２に搭載されており、ＣＰＵ−Ｃ０４は、アプリケーションＡ０４、Ａ０５を実行すると共にＥＣＵ−Ｅ０３に搭載されている。
【００４９】
また、バスＢ１にＣＰＵ−Ｃ０１およびＣＰＵ−Ｃ０３が接続されており、バスＢ２にＣＰＵ−Ｃ０２およびＣＰＵ−Ｃ０４が接続されている。同じバスに接続されていないＣＰＵ同士が通信するためには、他のＣＰＵを中継点（以下、ゲートウェイという）として用いる必要がある。例えば、ＣＰＵ−Ｃ０３とＣＰＵ−Ｃ０４とが通信するためには、通信データをＣ０３→Ｃ０１→Ｃ０２→Ｃ０４またはその逆の経路で受け渡ししなければならない。この場合、Ｃ０１―Ｃ０２間の通信は、ＣＰＵ間通信となる。
【００５０】
通信リソース設計情報テーブルは、１つのＣＰＵにつき１つ作成されるようになっている。各通信リソース設計情報テーブルは、図８に示すように、通信システム６０においてやりとりされる通信データ毎に、概要データ、関連性判定データ、詳細データ、およびリソースマッピングデータを有している。
【００５１】
概要データは、対象となる通信データのネットワーク名（すなわち、当該通信データがソフトウェアＰＦ（例えばデバイスドライバ）から参照されるときの名称）、当該通信データを搬送するデータフレームの名称、当該通信データの発信元である送信ＣＰＵ、当該通信データの宛先である受信ＣＰＵの情報を含んでいる。
【００５２】
関連性判定データは、当該通信データの配送に、自ＣＰＵ（すなわち、この通信リソース設計情報テーブルの対象となるＣＰＵ）が関与するか否かの情報（以下自ＣＰＵ関連情報という）、および、当該ＣＰＵが当該通信データのゲートウェイとなるか否かの情報（以下、ＧＷ情報という）を含む。なお、当該通信データが当該ＣＰＵに関与するか否かとは、当該通信データの通信経路内に自ＣＰＵが含まれるか否かをいう。
【００５３】
詳細データは、当該通信データの詳細（例えば、送信周期）を示すデータである。リソースマッピングデータは、当該通信データが、アプリケーション設計情報テーブル中に記載された通信データのどれに相当するかを示すデータである。すなわち、当該通信データの、アプリケーション名とネットワーク名とを対応付けるデータである。
【００５４】
本実施形態においては、ユーザは、ステップ１１０、１２０において、コンフィグツール７に対して手作業で各種情報を入力することで、アプリケーション設計情報テーブルおよびシステム設計情報テーブルの作成を完了する。
【００５５】
しかし、ステップ１３０においては、通信リソース設計情報テーブルの一部をコンピュータ５０が自動的に作成する。図９に、ステップ１３０の作業の手順をより詳細に示す。この図に示す通り、ステップ１３０においては、まず通信リソース設計情報テーブル中の概要データをユーザが手入力で設定し（ステップ１３２）、続いてリソースマッピングデータをユーザが手入力で設定し（ステップ１３４）、続いて関連性判定データをコンピュータ５０が自動的に生成し（ステップ１３６）、最後に、自ＣＰＵ関連情報が「関連あり」となった通信データについての詳細データを、ユーザが手入力で設定する（ステップ１３８）。なお、ステップ１３２、１３４、１３８における手入力においては、ユーザは通信仕様６のデータを参照する。そして、演算回路は、手作業等により入力されたデータを、自らのハードディスクドライブに記録する。
【００５６】
ここで、ステップ１３６における関連性判定データの生成時に、コンピュータ５０の演算回路が実行する処理のフローチャートを、図１０に示す。演算回路は、コンフィグツール７の実行中に、ユーザが関連性判定データ生成を指示する所定の操作をコンピュータ５０の図示しない操作装置に対して行うことで、この処理を開始する。
【００５７】
この処理において、演算回路は、まずステップ３１０で、各システム設計情報テーブルの関連性判定データ中のすべての自ＣＰＵ関連情報およびＧＷ情報の値を「無し」に初期化する。
【００５８】
続いて、アプリケーション設計情報テーブル中のすべての通信データ（図６の例では、アプリケーションデータ名Ｄ１、アプリケーションデータ名Ｄ２、アプリケーションデータ名Ｄ３等によって参照される通信データ）のそれぞれについて、ステップ３２０、３３０、３４０の処理を１回ずつ実行する。すなわち、アプリ通信データの数だけ、ステップ３２０〜３４０のループが繰り返される。
【００５９】
以下、ループのある回において対象となる通信データを、対象データという。あるループにおいて、ステップ３２０においては、演算回路は、アプリケーション設計情報テーブルを参照することで、対象データの発信元の送信アプリケーションと、対象データの宛先の受信アプリケーションとを特定する。例えば、対象データがデータＤ１である場合、送信アプリケーションはアプリケーションＡ０２となり、受信アプリケーションはアプリケーションＡ０１、Ａ０３となる。
【００６０】
続いてステップ３３０では、ステップ３２０で特定した送信アプリケーションおよび受信アプリケーションと、システム設計情報テーブルとを用いて、対象データの経路パターンを特定する。経路パターンとは、通信システム６０中で対象データがどのような経路で送信アプリケーションから受信アプリケーションまで到達するかについてのパターンである。
【００６１】
図１１に、６つの経路パターンを模式的に示し、図１２に、図１１のパターンを説明するための仮想的なＣＰＵ間の接続形態を示す。タイプ１の経路パターンは、発信元ＣＰＵから宛先ＣＰＵまで、ＣＰＵ間通信（ジグザグ線の矢印で示す）によって対象データが届けられるパターンである。図１２においては、ＣＰＵ−Ａ→ＣＰＵ間線Ｘ→ＣＰＵ−Ｂの経路が、このタイプ１の一例に相当する。
【００６２】
タイプ２の経路パターンは、発信元ＣＰＵから宛先ＣＰＵまで、ＥＣＵ間の通信バスを介する通信（実線の直線矢印で示す）によって対象データが届けられるパターンである。図１２においては、ＣＰＵ−Ａ→ノードＮ１→ノードＮ２→ノードＮ３→ノードＮ４→ＣＰＵ−Ｂの経路が、このタイプ２の一例に相当する。
【００６３】
タイプ３の経路パターンは、発信元ＣＰＵから宛先ＣＰＵまで、ゲートウェイとなるＣＰＵを介して対象データが届けられ、発信元ＣＰＵからゲートウェイＣＰＵまでは、ＣＰＵ間通信が用いられ、ゲートウェイＣＰＵから宛先ＣＰＵまでは、ＥＣＵ間の通信バスを介した通信が用いられるパターンである。図１２においては、ＣＰＵ−Ａ→ＣＰＵ間線Ｘ→ＣＰＵ−Ｂ→ノードＮ５→ノードＮ６→ノードＮ７→ノードＮ８→ＣＰＵ−Ｅの経路が、このタイプ３の一例に相当する。
【００６４】
タイプ４の経路パターンは、発信元ＣＰＵから宛先ＣＰＵまで、ゲートウェイとなるＣＰＵを介して対象データが届けられ、発信元ＣＰＵからゲートウェイＣＰＵまでは、ＥＣＵ間の通信バスを介した通信が用いられ、ゲートウェイＣＰＵから宛先ＣＰＵまでは、ＣＰＵ間通信が用いられるパターンである。図１２においては、ＣＰＵ−Ｄ→ノードＮ９→ノードＮ１０→ノードＮ１１→ノードＮ１２→ＣＰＵ−Ａ→ＣＰＵ間線Ｘ→ＣＰＵ−Ｂの経路が、このタイプ４の一例に相当する。
【００６５】
タイプ５の経路パターンは、発信元ＣＰＵから宛先ＣＰＵまで、ゲートウェイとなるＣＰＵを介して対象データが届けられ、発信元ＣＰＵからゲートウェイＣＰＵまでは、ＥＣＵ間のある通信バスを介した通信が用いられ、ゲートウェイＣＰＵから宛先ＣＰＵまでは、ＥＣＵ間の別の通信バスを介した通信が用いられるパターンである。図１２においては、ＣＰＵ−Ｄ→ノードＮ９→ノードＮ１０→ノードＮ１１→ノードＮ１２→ノードＮ１→ノードＮ２→ノードＮ１３→ノードＮ１４→ＣＰＵ−Ｅの経路が、このタイプ５の一例に相当する。なお、ノードＮ１２からノードＮ１へのデータの移動は、ＣＰＵ−Ａのソフトウェア実行による処理ではなく、通信制御を行う専用のＥＣＵハードウェア（図中ではＥＣＵ−ＨＷ）によって実現されるようになっている。
【００６６】
タイプ６の経路パターンは、発信元ＣＰＵから宛先ＣＰＵまで、２つのゲートウェイとなるＣＰＵを介して対象データが届けられ、発信元ＣＰＵから１番目のゲートウェイＣＰＵまでは、ＥＣＵ間のある通信バスを介した通信が用いられ、１番目のゲートウェイＣＰＵから２番目のゲートウェイＣＰＵまでは、ＣＰＵ間通信が用いられ、２番目のゲートウェイＣＰＵから宛先ＣＰＵまでは、ＥＣＵ間の別の通信バスを介した通信が用いられるパターンである。図１２においては、ＣＰＵ−Ｄ→ノードＮ９→ノードＮ１０→ノードＮ１１→ノードＮ１２→ＣＰＵ−Ａ→ＣＰＵ間線Ｘ→ＣＰＵ−Ｂ→ノードＮ４→ノードＮ３→ノードＮ１３→ノードＮ１４→ＣＰＵ−Ｅの経路が、このタイプ６の一例に相当する。
【００６７】
ここで、図６における通信データＤ１を例にとって、演算回路のステップ３３０における具体的な処理内容を説明する。
【００６８】
まず、演算回路は、対象データＤ１について、発信元アプリケーションがアプリケーションＡ０２であり、宛先アプリケーションがアプリケーションＡ０１、０３であることを、ハードディスクドライブ中のアプリケーション設計情報テーブル（図６参照）から特定する。
【００６９】
続いて演算回路は、ハードディスクドライブ中のシステム設計情報テーブル（図７参照）に基づいて、アプリケーションＡ０２からアプリケーションＡ０１への経路は、ＣＰＵ−Ｃ０２からＣＰＵ−Ｃ０１への経路であることを特定する。
【００７０】
さらに演算回路は、当該システム設計情報テーブルに基づいて、アプリケーションＡ０２からアプリケーションＡ０３への経路は、ＣＰＵ−Ｃ０２からＣＰＵ−Ｃ０３への経路であることを特定する。
【００７１】
更に続いて演算回路は、ＣＰＵ−Ｃ０２とＣＰＵ−Ｃ０１が同じＥＣＵ−Ｅ０１に搭載されていることをシステム設計情報テーブルに基づいて特定することで、ＣＰＵ−Ｃ０２からＣＰＵ−Ｃ０１への経路は、ＣＰＵ間通信による経路であることを特定し、さらに、この特定結果に基づいて、アプリケーションＡ０２からアプリケーションＡ０１への経路は、タイプ１の経路パターンに該当することを特定する。
【００７２】
更に続いて演算回路は、ＣＰＵ−Ｃ０２とＣＰＵ−Ｃ０３は同じ通信バスに接続されていないことを特定し、その特定結果に基づいて、ＣＰＵ−Ｃ０３と同じ通信バスに接続されている他のＣＰＵをシステム設計情報テーブルから検索し、さらに、それらのうちＣＰＵ−Ｃ０２と通信可能なＣＰＵを特定する。この場合、ＣＰＵ−Ｃ０２と通信可能なＣＰＵとは、２つのバスＢ１、Ｂ２の両方に接続しているＣＰＵ、および、ＣＰＵ−Ｃ０２とＣＰＵ間通信可能なＥＣＵ（すなわちＣＰＵ−Ｃ０２と同一ＥＣＵ内にあるＣＰＵ）である。
【００７３】
本例においては、バスＢ１に接続し、かつＣＰＵ−Ｃ０２と直接通信可能なＣＰＵは、ＣＰＵ−Ｃ０１である。したがって、演算回路は、ＣＰＵ−Ｃ０２→ＣＰＵ間通信→ＣＰＵ−Ｃ０１→バスＢ１→ＣＰＵ−Ｃ０３という経路を、ＣＰＵ−Ｃ０２からＣＰＵ−Ｃ０３への経路であると特定し、さらに、この特定結果に基づいて、アプリケーションＡ０２からアプリケーションＡ０３への経路は、タイプ１、タイプ２、およびタイプ３の経路パターンを含むので、タイプ１、タイプ２、およびタイプ３の経路パターンに該当することを特定する。
【００７４】
続いてステップ３４０では、演算回路は、ハードディスクドライブ中の各システム設計情報テーブルのリソースマッピングデータに基づいて、対象データのアプリケーション名（本例ではＤ１）に対応するネットワーク名（本例ではＳ１）を特定し、特定した名称に該当するすべてのレコードにおける関連性判定データを、直前のステップ３４０で特定した経路パターンのタイプにあらかじめ割り当てられた決定方法で、決定する。
【００７５】
具体的には、経路パターンのタイプにあらかじめ割り当てられた決定方法とは、以下の通りである。直前のステップ３４０で特定した経路パターンのタイプがタイプ１またはタイプ２であり、かつ、対象となるレコードを含むシステム設計情報テーブルに対応するＣＰＵが、当該経路の発信元または宛先に対応する場合、当該対象となるレコード中の自ＣＰＵ関連データを「有り」に書き換える。
【００７６】
また、直前のステップ３４０で特定した経路パターンのタイプがタイプ３、４、６のうち少なくともいずれか１つに該当し、かつ、対象となるレコードを含むシステム設計情報テーブルに対応するＣＰＵが、当該経路のゲートウェイとなっている場合、当該対象となるレコード中のＧＷ情報を「有り」に書き換える。
【００７７】
また、直前のステップ３４０で特定した経路パターンのタイプがタイプ５に該当し、かつ、対象となるレコードを含むシステム設計情報テーブルに対応するＣＰＵが、当該経路のゲートウェイとなっている場合（すなわち、当該ＣＰＵのＥＣＵハードウェアを利用してある通信バスから別の通信バスへ対象データが送信される場合）、当該対象となるレコード中のＧＷ情報を「有り」に書き換える。
【００７８】
以上のようなステップ３２０〜３４０を演算回路が通信データ毎に繰り返すことで、複数の通信リソース設計情報テーブル中の関連性判定データが決定する。このように、コンピュータ５０が、コンフィギュレーションコードの作成に必要な関連性判定データを、ユーザが入力したアプリケーション設計情報テーブル、システム設計情報テーブル、概要データ、およびリソースマッピングデータの内容に基づいて、自動的に作成することができる。
【００７９】
すなわち、各通信データについて、アプリケーション設計情報テーブルの送信アプリケーション−受信アプリケーションの関係、およびシステム設計情報テーブルのシステム構成から、当該通信データの経路を特定し、さらにその経路パターンを特定し、当該経路パターンに対応付けられた方法で、通信データの配送にどのＣＰＵが関与するかの情報、すなわち関連性判定データを自動的に特定することができる。
【００８０】
ここで、図５のステップ１４０における、コンフィギュレーションコードの生成について説明する。ステップ１４０において、演算回路は、あるＣＰＵについてのコンフィギュレーションコードを作成するために、アプリケーション設計情報テーブル、および、当該ＣＰＵを対象とするシステム設計情報テーブルを参照することで、当該ＣＰＵが受け渡しに関与している通信データのアプリケーションのアプリケーション名を特定し、そのアプリケーション名を参照するための通信データ関数を作成して当該コンフィギュレーションコードに含ませ、また、当該ＣＰＵが関与していない通信データについての通信データ関数を作成しない。ここで、通信データ関数の具体的な内容は、あらかじめ定められている。
【００８１】
またステップ１４０において、演算回路は、あるＣＰＵについてのコンフィギュレーションコードを作成するために、アプリケーション設計情報テーブル、および、当該ＣＰＵを対象とするシステム設計情報テーブルを参照することで、当該ＣＰＵが受け渡しに関与している通信データの詳細情報を特定し、当該詳細情報を当該コンフィギュレーションコードに含ませ、また、当該ＣＰＵが関与していない通信データについての詳細情報を当該コンフィギュレーションコードに含ませない。
【００８２】
このようにして、コンフィグツール７において作成される各ＣＰＵ用のコンフィギュレーションコードには、通信リソース設計情報テーブルの関連性判定データの内容が反映される。したがって、当該ＣＰＵが送信も受信も行わず、かつゲートウェイにもならないような通信データ（すなわち当該ＣＰＵが通信に関与しない通信データ）については、そのデータの詳細情報を含まないように、かつ、そのデータを扱う通信データ関数を含まないように、コンフィギュレーションコードが生成される。その結果、生成される実行イメージのサイズが低減され、その結果、ＥＣＵのＲＯＭ容量をより効率的に利用することができる。
【００８３】
また、このようにしてコンフィグツール７において作成される各ＣＰＵ用のコンフィギュレーションコードには、通信リソース設計情報テーブルの関連性判定データの内容が反映されるので、当該ＣＰＵがどのデータのゲートウェイにもならない場合、その旨がコンフィギュレーションコードからわかるので、その場合には、演算回路は、リンクの際に、ソフトウェアＰＦのゲートウェイの実現に関する部分をリンク対象から除外することができる。したがって、生成される実行イメージのサイズが低減され、その結果、ＥＣＵのＲＯＭ容量をより効率的に利用することができる。
【００８４】
なお、上記実施形態においては、演算装置が、図５のステップ１１０においてアプリケーション設計情報テーブルの入力を受けることで第１記録手段の一例として機能し、ステップ１２０においてシステム設計情報テーブルの入力を受けることで第２記録手段の一例として機能し、ステップ１４０でコンフィギュレーションコードを生成することでコンフィギュレーションコード生成記録手段関連性記録手段の一例として機能し、図９のステップ１３６を実行することで関連性記録手段の一例として機能し、図１０のステップ３２０を実行することで第１特定手段の一例として機能し、ステップ３３０を実行することで第２特定手段の一例として機能し、ステップ３４０を実行することで第３特定手段の一例として機能する。
（他の実施形態）
なお、上記の実施形態において、演算回路は、アプリケーション設計情報テーブル、システム設計情報テーブル、通信リソース設計情報テーブルの概要データ、通信リソース設計情報テーブルのリソースマッピングデータ、および、通信リソース設計情報テーブルの詳細データの入力を、操作装置を介したて入力で受け付けて記憶するようになっているが、ＵＳＢメモリ等の携帯可能な記憶媒体に記憶されたそれらデータを読み出すことで、当該データの入力受け付けを実現するようになっていてもよいし、コンピュータネットワークを介してそれらデータを受信することで、当該データの入力受け付けを実現するようになっていてもよい。
【図面の簡単な説明】
【００８５】
【図１】複数のＥＣＵのそれぞれが車両内の通信バスＢ１、Ｂ２のいずれかまたは両方に接続されている状態の例を示す図である。
【図２】各ＣＰＵにおいて実行されるプログラム群の階層構造を示す図である。
【図３】各ＣＰＵに実行させるプログラムの実行イメージを生成する手順を概略的に示す図である。
【図４】コンフィギュレーションコードの生成の方法を概略的に示す図である。
【図５】コンフィギュレーションコードの作成の手順の概要を示すフローチャートである。
【図６】アプリケーション設計情報テーブルの一例を示す図表である。
【図７】システム設計情報テーブルの一例を示す図表である。
【図８】通信リソース設計情報テーブルの一例を示す図表である。
【図９】コンフィギュレーションコードの作成の手順における通信リソースの設定の詳細手順を示すフローチャートである。
【図１０】関連性判定データの作成のためにコンピュータ５０が実行する処理のフローチャートである。
【図１１】６つの経路パターンを模式的に示す図である。
【図１２】図１１のパターンを説明するための仮想的なＣＰＵ間の接続形態を示す図である。
【図１３】コンフィギュレーションコードの作成の手順における、従来の通信リソースの設定の詳細手順を示すフローチャートである。
【符号の説明】
【００８６】
１…ソフトウェアＰＦ、２…コンフィギュレーションコード、３…アプリケーション、
４…アプリケーション仕様、５…システム仕様、６…通信仕様、
７…コンフィグツール、８…コンフィギュレーションコード、５０…コンピュータ、
６０…通信システム、Ｂ１、Ｂ２…バス、Ｅ０１〜Ｅ０３…ＥＣＵ、
Ｃ０１〜Ｃ０５…ＣＰＵ、Ａ０１〜Ａ０５、Ｎ０１〜Ｎ１４…ノード。
【図１】
0004725557.tif 000002
【図２】
0004725557.tif 000003
【図３】
0004725557.tif 000004
【図４】
0004725557.tif 000005
【図５】
0004725557.tif 000006
【図６】
0004725557.tif 000007
【図７】
0004725557.tif 000008
【図８】
0004725557.tif 000009
【図９】
0004725557.tif 000010
【図１０】
0004725557.tif 000011
【図１１】
0004725557.tif 000012
【図１２】
0004725557.tif 000013
【図１３】
0004725557.tif 000014