情報処理装置
【課題】アプリケーションプログラム間の通信を低コストで行うことが可能な情報処理装置を提供すること。
【解決手段】外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、前記コントローラを制御するドライバと、を備え、前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、情報処理装置。
【解決手段】外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、前記コントローラを制御するドライバと、を備え、前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアプリケーションプログラムを実行する情報処理装置に関する。
【背景技術】
【０００２】
近年、特に車載制御装置の分野において、複数のＥＣＵ（Electronic Control Unit）によって実行されていた制御を統合して、一の（或いは、より少数の）ＥＣＵに実行させることが進められている。車両に搭載されるＥＣＵとしては、エンジンの点火制御等を行うエンジンＥＣＵ、ドアロックの施錠／解錠等を行うボデーＥＣＵ、電子制御式ブレーキ装置のソレノイド制御等を行うブレーキＥＣＵ、パワーステアリング装置を制御するステアリングＥＣＵ等、種々のものが存在する。
【０００３】
このように、複数の機能を統合した情報処理装置は、ハードウエア面のコストを低減することができるため、種々の分野で用いられている。
【０００４】
特許文献１には、車両に搭載されたＥＣＵを統合した場合における通信モジュールの制御に特徴を有する制御装置について記載されている。この制御装置では、ＥＣＵのアプリケーションに含まれるボデー制御アプリケーションやＡＦＳ制御アプリケーション等の複数のアプリケーションプログラムがそれぞれ異なる周期で制御処理を行う場合に、複数の制御モジュールのうち、アプリケーションの制御周期に整合した制御モジュールを用いて他のＥＣＵとの通信を行っている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−２７４７８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来の制御装置においては、統合されたＥＣＵにより実行されるアプリケーションプログラム間の通信を、どのようにして行うかについての考慮がなされていない。
【０００７】
仮に、内部バスを用いてアプリケーションプログラム間の通信を行う場合、アプリケーションプログラム毎に二重化されたハードウエアを備える必要があり、ＥＣＵの統合によるコスト低減の効果が限定的になる場合がある。
【０００８】
本発明はこのような課題を解決するためのものであり、アプリケーションプログラム間の通信を低コストで行うことが可能な情報処理装置を提供することを、主たる目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するための本発明の一態様は、
外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、
前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、
前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、
前記コントローラを制御するドライバと、を備え、
前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、
前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、
情報処理装置である。
【００１０】
この本発明の一態様によれば、アプリケーションプログラム間の通信を低コストで行うことができる。
【００１１】
本発明の一態様において、
前記外部機器との通信に用いられる送信バッファ及び受信バッファを備え、
前記複数のアプリケーションプログラム間の通信は、前記複数のアプリケーションプログラムのうち送信側のアプリケーションプログラムの指示により前記送信バッファに書き込まれたデータを、前記ドライバが前記受信バッファにコピーし、前記複数のアプリケーションプログラムのうち受信側のアプリケーションプログラムに受信通知を行うことによって実行されるものとしてもよい。
【００１２】
この場合、
受信識別子と受信対象の関係を規定したテーブルを備え、
前記ドライバは、前記送信バッファに書き込まれたデータに含まれる受信識別子を用いて前記テーブルを検索することにより、前記受信側のアプリケーションプログラムを特定するものとしてもよい。
【発明の効果】
【００１３】
本発明によれば、アプリケーションプログラム間の通信を低コストで行うことが可能な情報処理装置を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施例に係る情報処理装置１のハードウエア構成例である。
【図２】本発明の一実施例に係る情報処理装置１の機能構成例である。
【図３】受信識別子テーブル３６の一例である。
【図４】ＣＡＮドライバ２５により実行される送信処理の流れを示すフローチャートである。
【図５】ＣＡＮドライバ２５により実行される送信確認処理の流れを示すフローチャートである。
【図６】ＣＡＮドライバ２５により実行される疑似受信処理（Ａ）の流れを示すフローチャートである。
【図７】ＣＡＮドライバ２５により実行される送信確認バッファ処理（Ａ）の流れを示すフローチャートである。
【図８】ＣＡＮドライバ２５により実行される受信処理の流れを示すフローチャートである。
【図９】アプリケーションプログラムからの指示によるＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態遷移を示す図である。
【図１０】統合前の複数のＥＣＵの接続関係を例示した図である。
【図１１】本実施例とは異なるアーキテクチャによりＥＣＵ＿ＡとＥＣＵ＿Ｂを統合した場合の統合ＥＣＵの構成を例示した図である。
【図１２】本実施例の情報処理装置１によるアプリ間の通信の流れ等を示す図である。
【図１３】本実施例の情報処理装置１を、統合ＥＣＵとして実現するための開発処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態について、添付図面を参照しながら実施例を挙げて説明する。
【実施例】
【００１６】
以下、図面を参照し、本発明の一実施例に係る情報処理装置１について説明する。情報処理装置１は、車両に搭載された制御装置（ＥＣＵ）として好適に用いられるものであるが、これに限定されず、種々の用途に適用可能である。
【００１７】
［ハードウエア構成、基本機能］
図１は、本発明の一実施例に係る情報処理装置１のハードウエア構成例である。情報処理装置１は、主要な構成として、ＣＰＵ１０と、プログラムメモリ２０と、主記憶装置３０と、ＣＡＮ（Controller Area Network）コントローラ４０と、ＣＡＮトランシーバ５０と、周辺Ｉ／Ｏ６０と、周辺機器７０と、を備える。また、情報処理装置１は、図示された構成の他にも、ＨＤＤ（Hard Disk Drive）等の補助記憶装置、ドライブ装置等を備えてもよい。
【００１８】
ＣＰＵ１０は、例えば、プログラムカウンタ、命令フェッチユニット、命令キュー、命令発行部、汎用レジスタ、ＡＬＵ（Arithmetic Logic Unit）、ＭＵＬ（乗算器）、ＤＩＶ（除算器）、ＬＳＵ（Load Store Unit）その他の演算器を備える。ＣＰＵ１０は、プログラムメモリ２０から命令をフェッチし、演算結果や他の機器からロードした結果等を、内蔵する汎用レジスタや主記憶装置３０等に格納する。
【００１９】
プログラムメモリ２０は、例えば、ＲＯＭ（Read Only Memory）やＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）である。プログラムメモリ２０には、ＢＩＯＳ等の初期処理用プログラムの他、アプリケーションプログラムＡ（２１）、アプリケーションプログラムＢ（２２）（以下、単にアプリＡ、Ｂと表記する）、通信ミドルウエアＡ（２３）、通信ミドルウエアＢ（２４）、ＣＡＮドライバ２５、その他の各種プログラムが格納されている。各プログラムの内容については後述する。
【００２０】
ここで、アプリケーションプログラム及び対応する通信ミドルウエア等が二個存在するのはあくまで例示であり、本発明の適用上、アプリケーションプログラム等は複数であれば如何なる個数であってもよい。
【００２１】
主記憶装置３０は、例えばＲＡＭ（Random Access Memory）である。主記憶装置３０には、アプリＡ、Ｂの演算結果等が格納されるワーキングメモリとして機能する他、送信ＰＤＵ（Protocol Data Unit）バッファＡ（３１）、送信ＰＤＵバッファＢ（３２）、送信ＰＤＵフラグＡ（３３）、送信ＰＤＵフラグＢ（３４）、受信ＰＤＵバッファ３５、受信識別子テーブル３６等が格納される。
【００２２】
以下、数値符号を省略し、単に通信ミドルウエアＡ、Ｂ、送信ＰＤＵバッファＡ、Ｂ、送信ＰＤＵフラグＡ、Ｂ等と表記する。
【００２３】
送信ＰＤＵバッファＡ、Ｂ、送信ＰＤＵフラグＡ、Ｂ、及び受信ＰＤＵバッファ３５は、例えば専用領域として確保された主記憶装置３０上の領域である。受信識別子テーブル３６は、ＲＯＭ等に記憶されており、情報処理装置１の起動時等に主記憶装置にコピーされて用いられる。なお、これらのデータ領域又はデータのうち一部は、レジスタ、キャッシュメモリ、フラッシュメモリ等の他の記憶装置に設定・格納されてもよい。
【００２４】
ＣＡＮコントローラ４０は、ＣＡＮドライバ２５によって制御され、ＣＡＮトランシーバ５０を介して、ＣＡＮバス８０との間で種々のデータを送受信する。
【００２５】
ＣＡＮバス８０は、例えばツイストペアケーブルであり、差動電圧方式によって信号を伝達する。ＣＡＮバス８０には、例えば情報処理装置１以外の車載制御装置（ＥＣＵ）が通信ノードとして接続され、ＣＡＮバス８０を流れる信号を各通信ノードが参照できる構成となっている。ＣＡＮバス８０では、車両内通信として用いられているＣＡＮプロトコルに従って、情報の送受信が行われている。ＣＡＮプロトコルでは、ビットスタッフィングルール等の特徴的なルールが採用されている。
【００２６】
なお、ＣＡＮバス８０として例示した外部バスでは、ＣＡＮに限らず、ＬＩＮ（Local Interconnect Network）に代表される低速なボデー系通信プロトコル、ＭＯＳＴ（Media Oriented Systems Transport）に代表されるマルチメディア系通信プロトコル、ＦｌｅｘＲａｙ等の通信プロトコルが採用されても構わない。
【００２７】
ＣＡＮバス８０に情報を出力する際には、ＣＡＮコントローラ４０は、送信ＰＤＵバッファＡ又はＢに格納されたフレームを、ＮＲＺ（Non‐Return‐to‐Zero）方式でシリアルの送信信号に変換し、ＣＡＮトランシーバ５０に出力する。ＣＡＮコントローラ４０は、変換後の信号が“０（ドミナント）”のビットには論理レベルがLowの電圧を、“１（リセッシブ）”のビットには論理レベルがHighの電圧を出力する。ＣＡＮトランシーバ５０は、ＣＡＮコントローラ４０から取得した送信信号を差動電圧に変換してＣＡＮバス８０に出力する。すなわち、ＣＡＮトランシーバ５０は、送信データが「０」の時に、Ｈラインの電圧をハイレベル（例えば３．５［Ｖ］）にするとともにＬラインの電圧をローレベル（例えば１．５［Ｖ］）にし、送信データが「１」の時にＨラインの電圧をローレベル（例えば２．５［Ｖ］）にするとともにＬラインの電圧をハイレベル（例えば２．５［Ｖ］）にする。
【００２８】
ＣＡＮバス８０から情報を取得する際には、ＣＡＮトランシーバ５０は、ＣＡＮバス８０の差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号をＣＡＮコントローラ４０に出力する。ＣＡＮコントローラ４０の受信端子Ｒｘにはコンパレータが取り付けられており、所定の閾値電圧とＣＡＮトランシーバ５０からの受信信号とを比較して“１”、“０”のデジタルデータを生成して受信ＰＤＵバッファ３５に格納する。
【００２９】
周辺Ｉ／Ｏ６０は、例えば周辺機器７０とのインターフェースとして機能する。周辺機器７０は、例えば各種車載センサに接続されたＡ／Ｄ変換器であり、センサ出力値をデジタル値に変換して周辺Ｉ／Ｏ６０に出力する。周辺Ｉ／Ｏ６０に入力されたデータはＣＰＵ１０に伝達され、車両制御に用いられる。このほか、周辺機器７０としては、アクチュエータ、スイッチ等が該当し得る。
【００３０】
［ソフトウエア構成等］
図２は、本発明の一実施例に係る情報処理装置１の機能構成例である。図中、破線で示すブロックはソフトウエア機能であり、実線で示すブロックはハードウエア機能である。アプリＡ、Ｂは、それぞれ異なるタスクを処理するアプリケーションである。例えば、情報処理装置１が車両のエンジン制御装置である場合、アプリＡが点火時期制御を行い、アプリＢがスロットル開度制御やスタータモータ制御を行う等、役割が分担されている。
【００３１】
通信ミドルウエアＡ、Ｂ、及びＣＡＮドライバ２５は、オペレーティングシステムの一部として機能する。ＣＡＮドライバ２５は、ＣＡＮコントローラ４０に依存する下位層のソフトウエアであり、アプリＡ、Ｂ及び通信ミドルウエアＡ、Ｂは、ＣＡＮコントローラ４０に依存しない上位層のソフトウエアである。
【００３２】
通信ミドルウエアＡ、Ｂは、例えば、アプリＡ、Ｂからの処理要求をＣＡＮドライバ２５に対応した形式に変換し、ＣＡＮドライバ２５に出力する。また、通信ミドルウエアＡ、Ｂは、ＣＡＮドライバ２５から入力されるデータを受け付け、アプリＡ，Ｂが解釈可能な形式に変換等を行なってアプリＡ、Ｂに出力する。
【００３３】
ＣＡＮドライバ２５は、例えば、アプリＡ用インターフェース部２５Ａと、アプリＢ用インターフェース部２５Ｂと、共通処理部２５Ｃと、を備える。アプリＡ用インターフェース部２５Ａは、通信ミドルウエアＡからの処理要求を共通処理部２５Ｃに伝達し、共通処理部２５Ｃから入力されるデータを通信ミドルウエアＡに出力する。アプリＢ用インターフェース部２５Ｂは、通信ミドルウエアＢからの処理要求を共通処理部２５Ｃに伝達し、共通処理部２５Ｃから入力されるデータを通信ミドルウエアＢに出力する。共通処理部２５Ｃは、ＣＡＮコントローラ４０に対しては、ＣＡＮコントローラ４０を制御するためのレジスタへの書き込み等を行う。
【００３４】
以下、ＣＡＮドライバ２５による送受信処理について、より詳細に説明する。ＣＡＮドライバ２５は、受信識別子テーブル３６を参照して、データを受信するアプリケーションプログラムを特定する。
【００３５】
図３は、受信識別子テーブル３６の一例である。図中、ＩＦ−ＡはアプリＡ用インターフェース部２５Ａを示し、ＩＦ−ＢはアプリＢ用インターフェース部２５Ｂを示している。すなわち、ＣＡＮドライバ２５は、識別子が０ｘ１０であれば、アプリＡ用インターフェース部２５Ａ、通信ミドルウエアＡを介してアプリＡにデータを受信させると共に、アプリＢ用インターフェース部２５Ｂ、通信ミドルウエアＢを介してアプリＢにもデータを受信させる。また、ＣＡＮドライバ２５は、識別子が０ｘ１２０であれば、アプリＡ用インターフェース部２５Ａ、通信ミドルウエアＡを介してアプリＡにデータを受信させる。また、ＣＡＮドライバ２５は、識別子が０ｘ２０５であれば、アプリＢ用インターフェース部２５Ｂ、通信ミドルウエアＢを介してアプリＢにデータを受信させる。
【００３６】
受信識別子テーブル３６は、いずれのアプリケーションプログラムも受信しないデータについての識別子は登録していない。これによって、テーブルのデータサイズを低減することができる。
【００３７】
なお、ＣＡＮドライバ２５がテーブルを参照して受信先を特定する構成に代えて、通信ミドルウエアＡ、Ｂがそれぞれ個別にテーブルを管理し、入力されたデータに付随する識別子を判別してアプリＡ、Ｂにデータを受信させるかどうかを判断してもよい。
【００３８】
送信ＰＤＵフラグＡ、Ｂは、例えば、何も処理を行っていないことを表す“Empty”、送信中であることを表す“Sending”、送信待ちであることを表す“Waiting”の三値をとり得る。ＣＡＮドライバ２５は、送信ＰＤＵフラグＡ、Ｂの内容を参照し、各アプリによるデータ送信段階を判別する。以下、処理フローを示しながらＣＡＮドライバ２５の処理について説明する。
【００３９】
［処理フロー］
ＣＡＮドライバ２５は、〔１〕アプリケーションプログラムから送信指示がなされたとき、〔２〕ＣＡＮコントローラ４０から送信確認割り込みを受けたとき、〔３〕ＣＡＮコントローラ４０から受信通知割り込みを受けたときに、以下に説明する処理を行う。送信確認割り込みとは、ＣＡＮコントローラ４０が送信動作を完了したときにＣＡＮコントローラ４０からＣＡＮドライバ２５に出力される通知である。
【００４０】
〔１〕アプリケーションプログラムから送信指示がなされたとき
この場合、ＣＡＮドライバ２５は、送信処理を行う。図４は、ＣＡＮドライバ２５により実行される送信処理の流れを示すフローチャートである。ここでは、アプリＡから送信指示がなされたものとするが、アプリＢから送信指示がなされた場合は、フローの説明中のアプリＡとアプリＢをそっくり入れ替えればよい。
【００４１】
まず、ＣＡＮドライバ２５は、送信ＰＤＵフラグＡが“Empty”であるか否かを判定する（Ｓ１００）。
【００４２】
ＣＡＮドライバ２５は、送信ＰＤＵフラグＡが“Empty”である場合は、アプリＡから通信ミドルウエアＡ、アプリＡ用インターフェース２５Ａを介して入力された送信ＰＤＵデータを、送信ＰＤＵバッファＡにコピーする（Ｓ１０２）。
【００４３】
次に、ＣＡＮドライバ２５は、送信ＰＤＵフラグＢが“Sending”であるか否かを判定する（Ｓ１０４）。送信ＰＤＵフラグＢが“Sending”でない場合は、アプリＢの指示によるデータ送信中ではないため、送信ＰＤＵフラグＡを“Sending”に変更し（Ｓ１０６）、ＣＡＮコントローラ４０に対して送信ＰＤＵバッファＡに格納されている「ＩＤ、長さ、データ」を設定し、送信のトリガーをかける（Ｓ１０８）。
【００４４】
送信のトリガーは、前述のように、ＣＡＮコントローラ４０内のレジスタに値を書き込むこと等によって行われる。
【００４５】
一方、ＣＡＮドライバ２５は、送信ＰＤＵフラグＢが“Sending”である場合は、アプリＢの指示によるデータ送信中であるため、送信ＰＤＵフラグＡを“Waiting”に変更する（Ｓ１１０）。
【００４６】
Ｓ１０４でいずれの判定を得た場合も、ＣＡＮドライバ２５は、戻り値「ＣＡＮ＿ＯＫ」をアプリＡに返す（Ｓ１１２）。
【００４７】
ＣＡＮドライバ２５は、Ｓ１００において送信ＰＤＵフラグＡが“Empty”でないと判定された場合は、戻り値「ＣＡＮ＿ＢＵＳＹ」をアプリＡに返す（Ｓ１１４）。
【００４８】
戻り値「ＣＡＮ＿ＢＵＳＹ」がアプリＡに返されるのは、アプリＡ自身が、直前に指示した送信処理が未だ完了していない場面であり、アプリＡの設計上、想定内の場面である。一方、他のアプリ（アプリＢ）のための送信処理途中にアプリＡから送信指示がなされた場合には、送信ＰＤＵフラグＡが“Waiting”に変更され、後に図５のフローで待ち状態が解除されて送信が行われる。この結果、アプリＡから見ると、単に処理がある程度遅延したのに過ぎず、戻り値「ＣＡＮ＿ＢＵＳＹ」が返されることもないため、アプリＡの設計上、想定外の事象は生じない。これによって、後述する機能統合前のソフトウエアに大きな変更をすることなく、機能統合を行うことができる。
【００４９】
〔２〕ＣＡＮコントローラ４０から送信確認割り込みを受けたとき
この場合、ＣＡＮドライバ２５は、送信確認処理を行う。図５は、ＣＡＮドライバ２５により実行される送信確認処理の流れを示すフローチャートである。
【００５０】
まず、ＣＡＮドライバ２５は、送信ＰＤＵフラグＡが“Sending”であるか否かを判定する（Ｓ２００）。
【００５１】
送信ＰＤＵフラグＡが“Sending”である場合は、図６に示す疑似受信処理（Ａ）を行う（Ｓ２１０〜Ｓ２２０）。図６は、ＣＡＮドライバ２５により実行される疑似受信処理（Ａ）の流れを示すフローチャートである。疑似受信処理とは、アプリケーションプログラム間の送受信を、ＣＡＮバス８０を介した通信に擬して行う処理であり、これを採用することによって、後述する機能統合が容易となる。
【００５２】
ＣＡＮドライバ２５は、疑似受信処理において、まず送信ＰＤＵバッファＡから受信識別子を読み出し（Ｓ２１０）、読み出した受信識別子を用いて図３に示す受信識別子テーブル３６を検索する（Ｓ２１２）。そして、対応行が存在するか否かを判定する（Ｓ２１４）。
【００５３】
対応行が存在する場合、受信対象としてアプリＢが指定されているか（図３の例では、識別子が０ｘ１０又は０ｘ２０５であるか）否かを判定する（Ｓ２１６）。
【００５４】
受信対象としてアプリＢが指定されている場合、アプリＡからアプリＢへのデータ送信であるため、疑似受信を行う。すなわち、送信ＰＤＵバッファＡに格納されたデータを受信ＰＤＵバッファ３５にコピーし（Ｓ２１８）、アプリＢ用インターフェース部２５Ｂを介して通信ミドルウエアＢに受信通知呼び出しを行うことにより、アプリＢに受信ＰＤＵバッファ３５の内容を読み出させる（Ｓ２２０）。
【００５５】
なお、本実施例ではアプリＡ、Ｂしか存在しないため、対応行が存在する＝アプリＢへのデータ送信であるとみなしてもよく、Ｓ２１６の判定は省略することができる。アプリＡからアプリＡ自身へのデータ送信が行われることは考えにくいからである。
【００５６】
一方、Ｓ２１４において対応行が存在しないと判定された場合、及びＳ２１６において受信対象としてアプリＢが指定されていないと判定された場合は、疑似受信を行わない。これらを満たす場合とは、アプリＡから外部機器へのデータ送信が指示されたことを意味する。
【００５７】
ＣＡＮドライバ２５は、疑似受信処理（Ａ）を終了すると、ＣＡＮドライバ２５は、図７に示す送信確認バッファ処理（Ａ）を行う（Ｓ２３０〜Ｓ２３６）。図７は、ＣＡＮドライバ２５により実行される送信確認バッファ処理（Ａ）の流れを示すフローチャートである。
【００５８】
ＣＡＮドライバ２５は、送信確認バッファ処理において、まず送信ＰＤＵフラグＢが“Waiting”であるか否かを判定する（Ｓ２３０）。
【００５９】
送信ＰＤＵフラグＢが“Waiting”である場合、送信ＰＤＵフラグＢを“Sending”に変更し（Ｓ２３２）、ＣＡＮコントローラ４０に対して送信ＰＤＵバッファＢに格納されている「ＩＤ、長さ、データ」を設定し、送信のトリガーをかける（Ｓ２３４）。
【００６０】
そして、送信ＰＤＵフラグＡを“Empty”に変更し（Ｓ２３６）、送信確認バッファ処理を終了する。Ｓ２３０において送信ＰＤＵフラグＢが“Waiting”でなければ、単にＳ２３６の処理を行って送信確認バッファ処理を終了する。
【００６１】
ＣＡＮドライバ２５は、送信確認バッファ処理（Ａ）を終了すると、アプリＡ用インターフェース部２５Ａを介して通信ミドルウエアＡに受信通知呼び出しを行う（Ｓ２４０）。図中に呼び出し関数を例示する。
【００６２】
Ｓ２００において送信ＰＤＵフラグＡが“Sending”でないと判定された場合、ＣＡＮドライバ２５は、送信ＰＤＵフラグＢが“Sending”であるか否かを判定する（Ｓ２５０）。なお、本実施例ではアプリケーションプログラムはＡとＢのみであるため、Ｓ２５０の判定は省略しても構わない。
【００６３】
送信ＰＤＵフラグＡが“Sending”でない場合は、疑似受信処理（Ｂ）を行い（Ｓ２６０）、次に送信確認バッファ処理（Ｂ）を行う（Ｓ２７０）。疑似受信処理（Ｂ）は、図６に示した疑似受信処理（Ａ）においてＡとＢの関係をそっくり入れ替えたものであるため、説明を省略する。また、送信確認バッファ処理（Ｂ）についても、図７に示した送信確認バッファ処理（Ａ）においてＡとＢの関係をそっくり入れ替えたものであるため、説明を省略する。
【００６４】
ＣＡＮドライバ２５は、送信確認バッファ処理（Ｂ）を終了すると、アプリＢ用インターフェース部２５Ｂを介して通信ミドルウエアＢに受信通知呼び出しを行う（Ｓ２８０）。
【００６５】
〔３〕ＣＡＮコントローラ４０から受信通知割り込みを受けたとき
この場合、ＣＡＮドライバ２５は、受信処理を行う。図８は、ＣＡＮドライバ２５により実行される受信処理の流れを示すフローチャートである。
【００６６】
まず、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０の受信データをロックする（Ｓ３００）。
【００６７】
次に、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０から受信識別子を読み出し（Ｓ３０２）、読み出した受信識別子を用いて図３に示す受信識別子テーブル３６を検索する（Ｓ３０４）。そして、対応行が存在するか否かを判定する（Ｓ３０６）。
【００６８】
対応行が存在する場合、ＣＡＮコントローラ４０の受信データを受信ＰＤＵバッファ３５にコピーする（Ｓ３０８）。
【００６９】
そして、受信対象としてアプリＡが指定されているか（図３の例では、識別子が０ｘ１０又は０ｘ１２０であるか）否かを判定する（Ｓ３１０）。
【００７０】
受信対象としてアプリＡが指定されている場合、アプリＡ用インターフェース部２５Ａを介して通信ミドルウエアＡに受信通知呼び出しを行うことにより、アプリＡに受信ＰＤＵバッファ３５の内容を読み出させる（Ｓ３１２）。
【００７１】
続いて、ＣＡＮドライバ２５は、受信対象としてアプリＢが指定されているか（図３の例では、識別子が０ｘ１０又は０ｘ２０５であるか）否かを判定する（Ｓ３１４）。
【００７２】
受信対象としてアプリＢが指定されている場合、アプリＢ用インターフェース部２５Ｂを介して通信ミドルウエアＢに受信通知呼び出しを行うことにより、アプリＢに受信ＰＤＵバッファ３５の内容を読み出させる（Ｓ３１６）。
【００７３】
そして、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０の受信データを解放し（Ｓ３１８）、受信処理を終了する。
【００７４】
ここで、図４〜８のフローを実行する前に、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０を送受信可能な状態に遷移させる必要がある。ＣＡＮドライバ２５の共通処理部２５Ｃは、アプリＡ用インターフェース部２５Ａ又はアプリＢ用インターフェース部２５Ｂが受け付けたアプリＡ又はＢからの指示によって、ＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態を図９に示すように遷移させる。図９は、アプリケーションプログラムからの指示によるＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態遷移を示す図である。アプリＡ、Ｂは、ＣＡＮドライバ２５に対して、例えば図中“Score”と表記した状態指示信号を送信する。ＣＡＮドライバ２５は、アプリＡ、Ｂから受信した“Score”のうち最も値の大きいものに対応する状態に、ＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態を遷移させる。
【００７５】
なお、上記処理フローは、アプリ間の通信であってもＣＡＮバス８０にデータを出力する（ＣＡＮバス８０からの受信はしない）処理の流れとなっているが、ＣＡＮドライバ２５及びＣＡＮコントローラ４０の設定によって、係るデータ出力をしない構成としてもよい。例えば、ＣＡＮドライバ２５が受信識別子を判別して内部通信であると判定した場合には、ＣＡＮコントローラ４０に対して所定領域のレジスタ書き込み等を行い、これを受けたＣＡＮコントローラ４０は、ＣＡＮバス８０へのデータ出力を行わず送信確認割り込みを擬似的に行うように設定してもよい。
【００７６】
また、上記処理フローは、Inner Priority Inversionの問題について考慮していないが、係る問題は、アプリＡ用インターフェース部２５Ａ、アプリＢ用インターフェース部２５Ｂの下位層に位置づけられる機能によって解決できる。具体的には、送信ＰＤＵバッファＡ、Ｂをそれぞれ多重化し、送信時にはバッファ上にある“Waiting”状態のデータ間で優先順位を判定して最も優先順位の高いデータをＣＡＮコントローラ４０に設定して送信トリガをかけ、“Sending”状態に移行させる。また、“Sending”状態のデータについても、バッファ上にある“Waiting”状態のデータ中で、“Sending”状態のデータよりも優先順位が高いデータが存在する場合には、“Sending”状態のデータの送信を中止し、優先順位の高いデータをＣＡＮコントローラ４０に設定して送信トリガをかけ、“Sending”状態に移行させてもよい。
【００７７】
［機能統合との関係］
本実施例の情報処理装置１は、前述のように、元々別体として存在していた複数の制御装置等（以下、ＥＣＵと称する）を一個の装置に統合した統合ＥＣＵに、好適に適用される。図１０は、統合前の複数のＥＣＵの接続関係を例示した図である。図示するように、統合前の構成では、ＥＣＵ＿Ａ、ＥＣＵ＿Ｂ、ＥＣＵ‐ＣがＣＡＮバスに接続され、ＣＡＮバスによってＥＣＵ間の通信が可能な構成となっている。係る構成では、各ＥＣＵは、それぞれ通信ミドルウエア、ＣＡＮドライバ、ＣＡＮコントローラ、ＣＡＮトランシーバを備えている。
【００７８】
図１１は、本実施例とは異なるアーキテクチャによりＥＣＵ＿ＡとＥＣＵ＿Ｂを統合した場合の統合ＥＣＵの構成を例示した図である。係る構成では、ＥＣＵ＿Ａ、ＥＣＵ＿Ｂに搭載されていたアプリＡ、Ｂは、それぞれ専用の通信ミドルウエア、ＣＡＮドライバ、ＣＡＮコントローラを備えており、ＣＡＮトランシーバのみが共通化されている。この結果、通信ミドルウエアやＣＡＮドライバに関しては統合前後で余り修正を加える必要が無いものの、ＣＡＮコントローラを二個備えることにより、コスト低減の効果が十分でない。
【００７９】
更に、図１１の構成では、アプリＡからアプリＢにデータ送信する場合、内部バス８０*を備える必要がある。ＣＡＮトランシーバは共通化されているため、アプリＡのための送信動作と、アプリＢのための受信動作を同時に行うことができないからである。このように、内部バスを備える必要性等が、ＥＣＵの統合においてコスト低減の面からネックとなる場合があった。図１１における太線矢印は、アプリ間の通信の流れを示し、太線破線の矢印は、統合ＥＣＵと他のＥＣＵとの間の通信の流れを示している。
【００８０】
図１２は、本実施例の情報処理装置１によるアプリ間の通信の流れ等を示している。図１２における太線矢印は、アプリ間の通信の流れを示し、太線破線の矢印は、統合ＥＣＵと他のＥＣＵとの間の通信の流れを示している。
【００８１】
また、図１３は、本実施例の情報処理装置１を、統合ＥＣＵとして実現するための開発処理の流れを示すフローチャートである。
【００８２】
まず、ＥＣＵ＿Ａが実行していたアプリケーションプログラム及び通信ミドルウエアを抽出し（Ｓ４００）、次いでＥＣＵ＿Ｂが実行していたアプリケーションプログラム及び通信ミドルウエアを抽出する（Ｓ４０２）。
【００８３】
次に、マイコン初期設定をコーディングする（Ｓ４０４）。係る処理は、ＣＡＮドライバ２５におけるアプリケーションプログラム及び通信ミドルウエアの設定部分を含む。
【００８４】
次に、ＣＡＮドライバ２５と、抽出したソフトウエアと、初期設定部分を対象マイコンに実装する（Ｓ４０６）。
【００８５】
そして、動作確認を行い（Ｓ４０８）、開発処理を終了する。
【００８６】
［まとめ］
本実施例の情報処理装置１では、上位層のアプリＡ、Ｂ及び通信ミドルウエアＡ、Ｂに関しては統合前のものに余り修正を加える必要が無く、ＣＡＮドライバ２５にのみ特徴的な修正を加えることでアプリケーションプログラム間の通信を実現することができる。また、内部バスを用いる必要が無く、メモリ上に設定されたバッファやフラグを用いてアプリケーションプログラム間の通信を行うため、アプリケーションプログラム間の通信を低コストで実現することができる。
【００８７】
更に、本実施例の情報処理装置１では、受信識別子テーブル３６を用いてＣＡＮドライバ２５が受信アプリの判別を行うため、上位層の通信ミドルウエアが受信可否の判別をする必要が無く、上位層のソフトウエア負荷を軽減することができる。
【００８８】
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【符号の説明】
【００８９】
１ 情報処理装置
１０ ＣＰＵ
２０ プログラムメモリ
２１ アプリケーションプログラムＡ
２２ アプリケーションプログラムＢ
２３ 通信ミドルウエアＡ
２４ 通信ミドルウエアＢ
２５ ＣＡＮドライバ
２５Ａ アプリＡ用インターフェース部
２５Ｂ アプリＢ用インターフェース部
２５Ｃ 共通処理部
３０ 主記憶装置
３１ 送信ＰＤＵバッファＡ
３２ 送信ＰＤＵバッファＢ
３３ 送信ＰＤＵフラグＡ
３４ 送信ＰＤＵフラグＢ
３５ 受信ＰＤＵバッファ
３６ 受信識別子テーブル
４０ ＣＡＮコントローラ
５０ ＣＡＮトランシーバ
６０ 周辺Ｉ／Ｏ
７０ 周辺機器
【技術分野】
【０００１】
本発明は、複数のアプリケーションプログラムを実行する情報処理装置に関する。
【背景技術】
【０００２】
近年、特に車載制御装置の分野において、複数のＥＣＵ（Electronic Control Unit）によって実行されていた制御を統合して、一の（或いは、より少数の）ＥＣＵに実行させることが進められている。車両に搭載されるＥＣＵとしては、エンジンの点火制御等を行うエンジンＥＣＵ、ドアロックの施錠／解錠等を行うボデーＥＣＵ、電子制御式ブレーキ装置のソレノイド制御等を行うブレーキＥＣＵ、パワーステアリング装置を制御するステアリングＥＣＵ等、種々のものが存在する。
【０００３】
このように、複数の機能を統合した情報処理装置は、ハードウエア面のコストを低減することができるため、種々の分野で用いられている。
【０００４】
特許文献１には、車両に搭載されたＥＣＵを統合した場合における通信モジュールの制御に特徴を有する制御装置について記載されている。この制御装置では、ＥＣＵのアプリケーションに含まれるボデー制御アプリケーションやＡＦＳ制御アプリケーション等の複数のアプリケーションプログラムがそれぞれ異なる周期で制御処理を行う場合に、複数の制御モジュールのうち、アプリケーションの制御周期に整合した制御モジュールを用いて他のＥＣＵとの通信を行っている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−２７４７８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来の制御装置においては、統合されたＥＣＵにより実行されるアプリケーションプログラム間の通信を、どのようにして行うかについての考慮がなされていない。
【０００７】
仮に、内部バスを用いてアプリケーションプログラム間の通信を行う場合、アプリケーションプログラム毎に二重化されたハードウエアを備える必要があり、ＥＣＵの統合によるコスト低減の効果が限定的になる場合がある。
【０００８】
本発明はこのような課題を解決するためのものであり、アプリケーションプログラム間の通信を低コストで行うことが可能な情報処理装置を提供することを、主たる目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するための本発明の一態様は、
外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、
前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、
前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、
前記コントローラを制御するドライバと、を備え、
前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、
前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、
情報処理装置である。
【００１０】
この本発明の一態様によれば、アプリケーションプログラム間の通信を低コストで行うことができる。
【００１１】
本発明の一態様において、
前記外部機器との通信に用いられる送信バッファ及び受信バッファを備え、
前記複数のアプリケーションプログラム間の通信は、前記複数のアプリケーションプログラムのうち送信側のアプリケーションプログラムの指示により前記送信バッファに書き込まれたデータを、前記ドライバが前記受信バッファにコピーし、前記複数のアプリケーションプログラムのうち受信側のアプリケーションプログラムに受信通知を行うことによって実行されるものとしてもよい。
【００１２】
この場合、
受信識別子と受信対象の関係を規定したテーブルを備え、
前記ドライバは、前記送信バッファに書き込まれたデータに含まれる受信識別子を用いて前記テーブルを検索することにより、前記受信側のアプリケーションプログラムを特定するものとしてもよい。
【発明の効果】
【００１３】
本発明によれば、アプリケーションプログラム間の通信を低コストで行うことが可能な情報処理装置を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施例に係る情報処理装置１のハードウエア構成例である。
【図２】本発明の一実施例に係る情報処理装置１の機能構成例である。
【図３】受信識別子テーブル３６の一例である。
【図４】ＣＡＮドライバ２５により実行される送信処理の流れを示すフローチャートである。
【図５】ＣＡＮドライバ２５により実行される送信確認処理の流れを示すフローチャートである。
【図６】ＣＡＮドライバ２５により実行される疑似受信処理（Ａ）の流れを示すフローチャートである。
【図７】ＣＡＮドライバ２５により実行される送信確認バッファ処理（Ａ）の流れを示すフローチャートである。
【図８】ＣＡＮドライバ２５により実行される受信処理の流れを示すフローチャートである。
【図９】アプリケーションプログラムからの指示によるＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態遷移を示す図である。
【図１０】統合前の複数のＥＣＵの接続関係を例示した図である。
【図１１】本実施例とは異なるアーキテクチャによりＥＣＵ＿ＡとＥＣＵ＿Ｂを統合した場合の統合ＥＣＵの構成を例示した図である。
【図１２】本実施例の情報処理装置１によるアプリ間の通信の流れ等を示す図である。
【図１３】本実施例の情報処理装置１を、統合ＥＣＵとして実現するための開発処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態について、添付図面を参照しながら実施例を挙げて説明する。
【実施例】
【００１６】
以下、図面を参照し、本発明の一実施例に係る情報処理装置１について説明する。情報処理装置１は、車両に搭載された制御装置（ＥＣＵ）として好適に用いられるものであるが、これに限定されず、種々の用途に適用可能である。
【００１７】
［ハードウエア構成、基本機能］
図１は、本発明の一実施例に係る情報処理装置１のハードウエア構成例である。情報処理装置１は、主要な構成として、ＣＰＵ１０と、プログラムメモリ２０と、主記憶装置３０と、ＣＡＮ（Controller Area Network）コントローラ４０と、ＣＡＮトランシーバ５０と、周辺Ｉ／Ｏ６０と、周辺機器７０と、を備える。また、情報処理装置１は、図示された構成の他にも、ＨＤＤ（Hard Disk Drive）等の補助記憶装置、ドライブ装置等を備えてもよい。
【００１８】
ＣＰＵ１０は、例えば、プログラムカウンタ、命令フェッチユニット、命令キュー、命令発行部、汎用レジスタ、ＡＬＵ（Arithmetic Logic Unit）、ＭＵＬ（乗算器）、ＤＩＶ（除算器）、ＬＳＵ（Load Store Unit）その他の演算器を備える。ＣＰＵ１０は、プログラムメモリ２０から命令をフェッチし、演算結果や他の機器からロードした結果等を、内蔵する汎用レジスタや主記憶装置３０等に格納する。
【００１９】
プログラムメモリ２０は、例えば、ＲＯＭ（Read Only Memory）やＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）である。プログラムメモリ２０には、ＢＩＯＳ等の初期処理用プログラムの他、アプリケーションプログラムＡ（２１）、アプリケーションプログラムＢ（２２）（以下、単にアプリＡ、Ｂと表記する）、通信ミドルウエアＡ（２３）、通信ミドルウエアＢ（２４）、ＣＡＮドライバ２５、その他の各種プログラムが格納されている。各プログラムの内容については後述する。
【００２０】
ここで、アプリケーションプログラム及び対応する通信ミドルウエア等が二個存在するのはあくまで例示であり、本発明の適用上、アプリケーションプログラム等は複数であれば如何なる個数であってもよい。
【００２１】
主記憶装置３０は、例えばＲＡＭ（Random Access Memory）である。主記憶装置３０には、アプリＡ、Ｂの演算結果等が格納されるワーキングメモリとして機能する他、送信ＰＤＵ（Protocol Data Unit）バッファＡ（３１）、送信ＰＤＵバッファＢ（３２）、送信ＰＤＵフラグＡ（３３）、送信ＰＤＵフラグＢ（３４）、受信ＰＤＵバッファ３５、受信識別子テーブル３６等が格納される。
【００２２】
以下、数値符号を省略し、単に通信ミドルウエアＡ、Ｂ、送信ＰＤＵバッファＡ、Ｂ、送信ＰＤＵフラグＡ、Ｂ等と表記する。
【００２３】
送信ＰＤＵバッファＡ、Ｂ、送信ＰＤＵフラグＡ、Ｂ、及び受信ＰＤＵバッファ３５は、例えば専用領域として確保された主記憶装置３０上の領域である。受信識別子テーブル３６は、ＲＯＭ等に記憶されており、情報処理装置１の起動時等に主記憶装置にコピーされて用いられる。なお、これらのデータ領域又はデータのうち一部は、レジスタ、キャッシュメモリ、フラッシュメモリ等の他の記憶装置に設定・格納されてもよい。
【００２４】
ＣＡＮコントローラ４０は、ＣＡＮドライバ２５によって制御され、ＣＡＮトランシーバ５０を介して、ＣＡＮバス８０との間で種々のデータを送受信する。
【００２５】
ＣＡＮバス８０は、例えばツイストペアケーブルであり、差動電圧方式によって信号を伝達する。ＣＡＮバス８０には、例えば情報処理装置１以外の車載制御装置（ＥＣＵ）が通信ノードとして接続され、ＣＡＮバス８０を流れる信号を各通信ノードが参照できる構成となっている。ＣＡＮバス８０では、車両内通信として用いられているＣＡＮプロトコルに従って、情報の送受信が行われている。ＣＡＮプロトコルでは、ビットスタッフィングルール等の特徴的なルールが採用されている。
【００２６】
なお、ＣＡＮバス８０として例示した外部バスでは、ＣＡＮに限らず、ＬＩＮ（Local Interconnect Network）に代表される低速なボデー系通信プロトコル、ＭＯＳＴ（Media Oriented Systems Transport）に代表されるマルチメディア系通信プロトコル、ＦｌｅｘＲａｙ等の通信プロトコルが採用されても構わない。
【００２７】
ＣＡＮバス８０に情報を出力する際には、ＣＡＮコントローラ４０は、送信ＰＤＵバッファＡ又はＢに格納されたフレームを、ＮＲＺ（Non‐Return‐to‐Zero）方式でシリアルの送信信号に変換し、ＣＡＮトランシーバ５０に出力する。ＣＡＮコントローラ４０は、変換後の信号が“０（ドミナント）”のビットには論理レベルがLowの電圧を、“１（リセッシブ）”のビットには論理レベルがHighの電圧を出力する。ＣＡＮトランシーバ５０は、ＣＡＮコントローラ４０から取得した送信信号を差動電圧に変換してＣＡＮバス８０に出力する。すなわち、ＣＡＮトランシーバ５０は、送信データが「０」の時に、Ｈラインの電圧をハイレベル（例えば３．５［Ｖ］）にするとともにＬラインの電圧をローレベル（例えば１．５［Ｖ］）にし、送信データが「１」の時にＨラインの電圧をローレベル（例えば２．５［Ｖ］）にするとともにＬラインの電圧をハイレベル（例えば２．５［Ｖ］）にする。
【００２８】
ＣＡＮバス８０から情報を取得する際には、ＣＡＮトランシーバ５０は、ＣＡＮバス８０の差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号をＣＡＮコントローラ４０に出力する。ＣＡＮコントローラ４０の受信端子Ｒｘにはコンパレータが取り付けられており、所定の閾値電圧とＣＡＮトランシーバ５０からの受信信号とを比較して“１”、“０”のデジタルデータを生成して受信ＰＤＵバッファ３５に格納する。
【００２９】
周辺Ｉ／Ｏ６０は、例えば周辺機器７０とのインターフェースとして機能する。周辺機器７０は、例えば各種車載センサに接続されたＡ／Ｄ変換器であり、センサ出力値をデジタル値に変換して周辺Ｉ／Ｏ６０に出力する。周辺Ｉ／Ｏ６０に入力されたデータはＣＰＵ１０に伝達され、車両制御に用いられる。このほか、周辺機器７０としては、アクチュエータ、スイッチ等が該当し得る。
【００３０】
［ソフトウエア構成等］
図２は、本発明の一実施例に係る情報処理装置１の機能構成例である。図中、破線で示すブロックはソフトウエア機能であり、実線で示すブロックはハードウエア機能である。アプリＡ、Ｂは、それぞれ異なるタスクを処理するアプリケーションである。例えば、情報処理装置１が車両のエンジン制御装置である場合、アプリＡが点火時期制御を行い、アプリＢがスロットル開度制御やスタータモータ制御を行う等、役割が分担されている。
【００３１】
通信ミドルウエアＡ、Ｂ、及びＣＡＮドライバ２５は、オペレーティングシステムの一部として機能する。ＣＡＮドライバ２５は、ＣＡＮコントローラ４０に依存する下位層のソフトウエアであり、アプリＡ、Ｂ及び通信ミドルウエアＡ、Ｂは、ＣＡＮコントローラ４０に依存しない上位層のソフトウエアである。
【００３２】
通信ミドルウエアＡ、Ｂは、例えば、アプリＡ、Ｂからの処理要求をＣＡＮドライバ２５に対応した形式に変換し、ＣＡＮドライバ２５に出力する。また、通信ミドルウエアＡ、Ｂは、ＣＡＮドライバ２５から入力されるデータを受け付け、アプリＡ，Ｂが解釈可能な形式に変換等を行なってアプリＡ、Ｂに出力する。
【００３３】
ＣＡＮドライバ２５は、例えば、アプリＡ用インターフェース部２５Ａと、アプリＢ用インターフェース部２５Ｂと、共通処理部２５Ｃと、を備える。アプリＡ用インターフェース部２５Ａは、通信ミドルウエアＡからの処理要求を共通処理部２５Ｃに伝達し、共通処理部２５Ｃから入力されるデータを通信ミドルウエアＡに出力する。アプリＢ用インターフェース部２５Ｂは、通信ミドルウエアＢからの処理要求を共通処理部２５Ｃに伝達し、共通処理部２５Ｃから入力されるデータを通信ミドルウエアＢに出力する。共通処理部２５Ｃは、ＣＡＮコントローラ４０に対しては、ＣＡＮコントローラ４０を制御するためのレジスタへの書き込み等を行う。
【００３４】
以下、ＣＡＮドライバ２５による送受信処理について、より詳細に説明する。ＣＡＮドライバ２５は、受信識別子テーブル３６を参照して、データを受信するアプリケーションプログラムを特定する。
【００３５】
図３は、受信識別子テーブル３６の一例である。図中、ＩＦ−ＡはアプリＡ用インターフェース部２５Ａを示し、ＩＦ−ＢはアプリＢ用インターフェース部２５Ｂを示している。すなわち、ＣＡＮドライバ２５は、識別子が０ｘ１０であれば、アプリＡ用インターフェース部２５Ａ、通信ミドルウエアＡを介してアプリＡにデータを受信させると共に、アプリＢ用インターフェース部２５Ｂ、通信ミドルウエアＢを介してアプリＢにもデータを受信させる。また、ＣＡＮドライバ２５は、識別子が０ｘ１２０であれば、アプリＡ用インターフェース部２５Ａ、通信ミドルウエアＡを介してアプリＡにデータを受信させる。また、ＣＡＮドライバ２５は、識別子が０ｘ２０５であれば、アプリＢ用インターフェース部２５Ｂ、通信ミドルウエアＢを介してアプリＢにデータを受信させる。
【００３６】
受信識別子テーブル３６は、いずれのアプリケーションプログラムも受信しないデータについての識別子は登録していない。これによって、テーブルのデータサイズを低減することができる。
【００３７】
なお、ＣＡＮドライバ２５がテーブルを参照して受信先を特定する構成に代えて、通信ミドルウエアＡ、Ｂがそれぞれ個別にテーブルを管理し、入力されたデータに付随する識別子を判別してアプリＡ、Ｂにデータを受信させるかどうかを判断してもよい。
【００３８】
送信ＰＤＵフラグＡ、Ｂは、例えば、何も処理を行っていないことを表す“Empty”、送信中であることを表す“Sending”、送信待ちであることを表す“Waiting”の三値をとり得る。ＣＡＮドライバ２５は、送信ＰＤＵフラグＡ、Ｂの内容を参照し、各アプリによるデータ送信段階を判別する。以下、処理フローを示しながらＣＡＮドライバ２５の処理について説明する。
【００３９】
［処理フロー］
ＣＡＮドライバ２５は、〔１〕アプリケーションプログラムから送信指示がなされたとき、〔２〕ＣＡＮコントローラ４０から送信確認割り込みを受けたとき、〔３〕ＣＡＮコントローラ４０から受信通知割り込みを受けたときに、以下に説明する処理を行う。送信確認割り込みとは、ＣＡＮコントローラ４０が送信動作を完了したときにＣＡＮコントローラ４０からＣＡＮドライバ２５に出力される通知である。
【００４０】
〔１〕アプリケーションプログラムから送信指示がなされたとき
この場合、ＣＡＮドライバ２５は、送信処理を行う。図４は、ＣＡＮドライバ２５により実行される送信処理の流れを示すフローチャートである。ここでは、アプリＡから送信指示がなされたものとするが、アプリＢから送信指示がなされた場合は、フローの説明中のアプリＡとアプリＢをそっくり入れ替えればよい。
【００４１】
まず、ＣＡＮドライバ２５は、送信ＰＤＵフラグＡが“Empty”であるか否かを判定する（Ｓ１００）。
【００４２】
ＣＡＮドライバ２５は、送信ＰＤＵフラグＡが“Empty”である場合は、アプリＡから通信ミドルウエアＡ、アプリＡ用インターフェース２５Ａを介して入力された送信ＰＤＵデータを、送信ＰＤＵバッファＡにコピーする（Ｓ１０２）。
【００４３】
次に、ＣＡＮドライバ２５は、送信ＰＤＵフラグＢが“Sending”であるか否かを判定する（Ｓ１０４）。送信ＰＤＵフラグＢが“Sending”でない場合は、アプリＢの指示によるデータ送信中ではないため、送信ＰＤＵフラグＡを“Sending”に変更し（Ｓ１０６）、ＣＡＮコントローラ４０に対して送信ＰＤＵバッファＡに格納されている「ＩＤ、長さ、データ」を設定し、送信のトリガーをかける（Ｓ１０８）。
【００４４】
送信のトリガーは、前述のように、ＣＡＮコントローラ４０内のレジスタに値を書き込むこと等によって行われる。
【００４５】
一方、ＣＡＮドライバ２５は、送信ＰＤＵフラグＢが“Sending”である場合は、アプリＢの指示によるデータ送信中であるため、送信ＰＤＵフラグＡを“Waiting”に変更する（Ｓ１１０）。
【００４６】
Ｓ１０４でいずれの判定を得た場合も、ＣＡＮドライバ２５は、戻り値「ＣＡＮ＿ＯＫ」をアプリＡに返す（Ｓ１１２）。
【００４７】
ＣＡＮドライバ２５は、Ｓ１００において送信ＰＤＵフラグＡが“Empty”でないと判定された場合は、戻り値「ＣＡＮ＿ＢＵＳＹ」をアプリＡに返す（Ｓ１１４）。
【００４８】
戻り値「ＣＡＮ＿ＢＵＳＹ」がアプリＡに返されるのは、アプリＡ自身が、直前に指示した送信処理が未だ完了していない場面であり、アプリＡの設計上、想定内の場面である。一方、他のアプリ（アプリＢ）のための送信処理途中にアプリＡから送信指示がなされた場合には、送信ＰＤＵフラグＡが“Waiting”に変更され、後に図５のフローで待ち状態が解除されて送信が行われる。この結果、アプリＡから見ると、単に処理がある程度遅延したのに過ぎず、戻り値「ＣＡＮ＿ＢＵＳＹ」が返されることもないため、アプリＡの設計上、想定外の事象は生じない。これによって、後述する機能統合前のソフトウエアに大きな変更をすることなく、機能統合を行うことができる。
【００４９】
〔２〕ＣＡＮコントローラ４０から送信確認割り込みを受けたとき
この場合、ＣＡＮドライバ２５は、送信確認処理を行う。図５は、ＣＡＮドライバ２５により実行される送信確認処理の流れを示すフローチャートである。
【００５０】
まず、ＣＡＮドライバ２５は、送信ＰＤＵフラグＡが“Sending”であるか否かを判定する（Ｓ２００）。
【００５１】
送信ＰＤＵフラグＡが“Sending”である場合は、図６に示す疑似受信処理（Ａ）を行う（Ｓ２１０〜Ｓ２２０）。図６は、ＣＡＮドライバ２５により実行される疑似受信処理（Ａ）の流れを示すフローチャートである。疑似受信処理とは、アプリケーションプログラム間の送受信を、ＣＡＮバス８０を介した通信に擬して行う処理であり、これを採用することによって、後述する機能統合が容易となる。
【００５２】
ＣＡＮドライバ２５は、疑似受信処理において、まず送信ＰＤＵバッファＡから受信識別子を読み出し（Ｓ２１０）、読み出した受信識別子を用いて図３に示す受信識別子テーブル３６を検索する（Ｓ２１２）。そして、対応行が存在するか否かを判定する（Ｓ２１４）。
【００５３】
対応行が存在する場合、受信対象としてアプリＢが指定されているか（図３の例では、識別子が０ｘ１０又は０ｘ２０５であるか）否かを判定する（Ｓ２１６）。
【００５４】
受信対象としてアプリＢが指定されている場合、アプリＡからアプリＢへのデータ送信であるため、疑似受信を行う。すなわち、送信ＰＤＵバッファＡに格納されたデータを受信ＰＤＵバッファ３５にコピーし（Ｓ２１８）、アプリＢ用インターフェース部２５Ｂを介して通信ミドルウエアＢに受信通知呼び出しを行うことにより、アプリＢに受信ＰＤＵバッファ３５の内容を読み出させる（Ｓ２２０）。
【００５５】
なお、本実施例ではアプリＡ、Ｂしか存在しないため、対応行が存在する＝アプリＢへのデータ送信であるとみなしてもよく、Ｓ２１６の判定は省略することができる。アプリＡからアプリＡ自身へのデータ送信が行われることは考えにくいからである。
【００５６】
一方、Ｓ２１４において対応行が存在しないと判定された場合、及びＳ２１６において受信対象としてアプリＢが指定されていないと判定された場合は、疑似受信を行わない。これらを満たす場合とは、アプリＡから外部機器へのデータ送信が指示されたことを意味する。
【００５７】
ＣＡＮドライバ２５は、疑似受信処理（Ａ）を終了すると、ＣＡＮドライバ２５は、図７に示す送信確認バッファ処理（Ａ）を行う（Ｓ２３０〜Ｓ２３６）。図７は、ＣＡＮドライバ２５により実行される送信確認バッファ処理（Ａ）の流れを示すフローチャートである。
【００５８】
ＣＡＮドライバ２５は、送信確認バッファ処理において、まず送信ＰＤＵフラグＢが“Waiting”であるか否かを判定する（Ｓ２３０）。
【００５９】
送信ＰＤＵフラグＢが“Waiting”である場合、送信ＰＤＵフラグＢを“Sending”に変更し（Ｓ２３２）、ＣＡＮコントローラ４０に対して送信ＰＤＵバッファＢに格納されている「ＩＤ、長さ、データ」を設定し、送信のトリガーをかける（Ｓ２３４）。
【００６０】
そして、送信ＰＤＵフラグＡを“Empty”に変更し（Ｓ２３６）、送信確認バッファ処理を終了する。Ｓ２３０において送信ＰＤＵフラグＢが“Waiting”でなければ、単にＳ２３６の処理を行って送信確認バッファ処理を終了する。
【００６１】
ＣＡＮドライバ２５は、送信確認バッファ処理（Ａ）を終了すると、アプリＡ用インターフェース部２５Ａを介して通信ミドルウエアＡに受信通知呼び出しを行う（Ｓ２４０）。図中に呼び出し関数を例示する。
【００６２】
Ｓ２００において送信ＰＤＵフラグＡが“Sending”でないと判定された場合、ＣＡＮドライバ２５は、送信ＰＤＵフラグＢが“Sending”であるか否かを判定する（Ｓ２５０）。なお、本実施例ではアプリケーションプログラムはＡとＢのみであるため、Ｓ２５０の判定は省略しても構わない。
【００６３】
送信ＰＤＵフラグＡが“Sending”でない場合は、疑似受信処理（Ｂ）を行い（Ｓ２６０）、次に送信確認バッファ処理（Ｂ）を行う（Ｓ２７０）。疑似受信処理（Ｂ）は、図６に示した疑似受信処理（Ａ）においてＡとＢの関係をそっくり入れ替えたものであるため、説明を省略する。また、送信確認バッファ処理（Ｂ）についても、図７に示した送信確認バッファ処理（Ａ）においてＡとＢの関係をそっくり入れ替えたものであるため、説明を省略する。
【００６４】
ＣＡＮドライバ２５は、送信確認バッファ処理（Ｂ）を終了すると、アプリＢ用インターフェース部２５Ｂを介して通信ミドルウエアＢに受信通知呼び出しを行う（Ｓ２８０）。
【００６５】
〔３〕ＣＡＮコントローラ４０から受信通知割り込みを受けたとき
この場合、ＣＡＮドライバ２５は、受信処理を行う。図８は、ＣＡＮドライバ２５により実行される受信処理の流れを示すフローチャートである。
【００６６】
まず、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０の受信データをロックする（Ｓ３００）。
【００６７】
次に、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０から受信識別子を読み出し（Ｓ３０２）、読み出した受信識別子を用いて図３に示す受信識別子テーブル３６を検索する（Ｓ３０４）。そして、対応行が存在するか否かを判定する（Ｓ３０６）。
【００６８】
対応行が存在する場合、ＣＡＮコントローラ４０の受信データを受信ＰＤＵバッファ３５にコピーする（Ｓ３０８）。
【００６９】
そして、受信対象としてアプリＡが指定されているか（図３の例では、識別子が０ｘ１０又は０ｘ１２０であるか）否かを判定する（Ｓ３１０）。
【００７０】
受信対象としてアプリＡが指定されている場合、アプリＡ用インターフェース部２５Ａを介して通信ミドルウエアＡに受信通知呼び出しを行うことにより、アプリＡに受信ＰＤＵバッファ３５の内容を読み出させる（Ｓ３１２）。
【００７１】
続いて、ＣＡＮドライバ２５は、受信対象としてアプリＢが指定されているか（図３の例では、識別子が０ｘ１０又は０ｘ２０５であるか）否かを判定する（Ｓ３１４）。
【００７２】
受信対象としてアプリＢが指定されている場合、アプリＢ用インターフェース部２５Ｂを介して通信ミドルウエアＢに受信通知呼び出しを行うことにより、アプリＢに受信ＰＤＵバッファ３５の内容を読み出させる（Ｓ３１６）。
【００７３】
そして、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０の受信データを解放し（Ｓ３１８）、受信処理を終了する。
【００７４】
ここで、図４〜８のフローを実行する前に、ＣＡＮドライバ２５は、ＣＡＮコントローラ４０を送受信可能な状態に遷移させる必要がある。ＣＡＮドライバ２５の共通処理部２５Ｃは、アプリＡ用インターフェース部２５Ａ又はアプリＢ用インターフェース部２５Ｂが受け付けたアプリＡ又はＢからの指示によって、ＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態を図９に示すように遷移させる。図９は、アプリケーションプログラムからの指示によるＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態遷移を示す図である。アプリＡ、Ｂは、ＣＡＮドライバ２５に対して、例えば図中“Score”と表記した状態指示信号を送信する。ＣＡＮドライバ２５は、アプリＡ、Ｂから受信した“Score”のうち最も値の大きいものに対応する状態に、ＣＡＮドライバ２５及びＣＡＮコントローラ４０の状態を遷移させる。
【００７５】
なお、上記処理フローは、アプリ間の通信であってもＣＡＮバス８０にデータを出力する（ＣＡＮバス８０からの受信はしない）処理の流れとなっているが、ＣＡＮドライバ２５及びＣＡＮコントローラ４０の設定によって、係るデータ出力をしない構成としてもよい。例えば、ＣＡＮドライバ２５が受信識別子を判別して内部通信であると判定した場合には、ＣＡＮコントローラ４０に対して所定領域のレジスタ書き込み等を行い、これを受けたＣＡＮコントローラ４０は、ＣＡＮバス８０へのデータ出力を行わず送信確認割り込みを擬似的に行うように設定してもよい。
【００７６】
また、上記処理フローは、Inner Priority Inversionの問題について考慮していないが、係る問題は、アプリＡ用インターフェース部２５Ａ、アプリＢ用インターフェース部２５Ｂの下位層に位置づけられる機能によって解決できる。具体的には、送信ＰＤＵバッファＡ、Ｂをそれぞれ多重化し、送信時にはバッファ上にある“Waiting”状態のデータ間で優先順位を判定して最も優先順位の高いデータをＣＡＮコントローラ４０に設定して送信トリガをかけ、“Sending”状態に移行させる。また、“Sending”状態のデータについても、バッファ上にある“Waiting”状態のデータ中で、“Sending”状態のデータよりも優先順位が高いデータが存在する場合には、“Sending”状態のデータの送信を中止し、優先順位の高いデータをＣＡＮコントローラ４０に設定して送信トリガをかけ、“Sending”状態に移行させてもよい。
【００７７】
［機能統合との関係］
本実施例の情報処理装置１は、前述のように、元々別体として存在していた複数の制御装置等（以下、ＥＣＵと称する）を一個の装置に統合した統合ＥＣＵに、好適に適用される。図１０は、統合前の複数のＥＣＵの接続関係を例示した図である。図示するように、統合前の構成では、ＥＣＵ＿Ａ、ＥＣＵ＿Ｂ、ＥＣＵ‐ＣがＣＡＮバスに接続され、ＣＡＮバスによってＥＣＵ間の通信が可能な構成となっている。係る構成では、各ＥＣＵは、それぞれ通信ミドルウエア、ＣＡＮドライバ、ＣＡＮコントローラ、ＣＡＮトランシーバを備えている。
【００７８】
図１１は、本実施例とは異なるアーキテクチャによりＥＣＵ＿ＡとＥＣＵ＿Ｂを統合した場合の統合ＥＣＵの構成を例示した図である。係る構成では、ＥＣＵ＿Ａ、ＥＣＵ＿Ｂに搭載されていたアプリＡ、Ｂは、それぞれ専用の通信ミドルウエア、ＣＡＮドライバ、ＣＡＮコントローラを備えており、ＣＡＮトランシーバのみが共通化されている。この結果、通信ミドルウエアやＣＡＮドライバに関しては統合前後で余り修正を加える必要が無いものの、ＣＡＮコントローラを二個備えることにより、コスト低減の効果が十分でない。
【００７９】
更に、図１１の構成では、アプリＡからアプリＢにデータ送信する場合、内部バス８０*を備える必要がある。ＣＡＮトランシーバは共通化されているため、アプリＡのための送信動作と、アプリＢのための受信動作を同時に行うことができないからである。このように、内部バスを備える必要性等が、ＥＣＵの統合においてコスト低減の面からネックとなる場合があった。図１１における太線矢印は、アプリ間の通信の流れを示し、太線破線の矢印は、統合ＥＣＵと他のＥＣＵとの間の通信の流れを示している。
【００８０】
図１２は、本実施例の情報処理装置１によるアプリ間の通信の流れ等を示している。図１２における太線矢印は、アプリ間の通信の流れを示し、太線破線の矢印は、統合ＥＣＵと他のＥＣＵとの間の通信の流れを示している。
【００８１】
また、図１３は、本実施例の情報処理装置１を、統合ＥＣＵとして実現するための開発処理の流れを示すフローチャートである。
【００８２】
まず、ＥＣＵ＿Ａが実行していたアプリケーションプログラム及び通信ミドルウエアを抽出し（Ｓ４００）、次いでＥＣＵ＿Ｂが実行していたアプリケーションプログラム及び通信ミドルウエアを抽出する（Ｓ４０２）。
【００８３】
次に、マイコン初期設定をコーディングする（Ｓ４０４）。係る処理は、ＣＡＮドライバ２５におけるアプリケーションプログラム及び通信ミドルウエアの設定部分を含む。
【００８４】
次に、ＣＡＮドライバ２５と、抽出したソフトウエアと、初期設定部分を対象マイコンに実装する（Ｓ４０６）。
【００８５】
そして、動作確認を行い（Ｓ４０８）、開発処理を終了する。
【００８６】
［まとめ］
本実施例の情報処理装置１では、上位層のアプリＡ、Ｂ及び通信ミドルウエアＡ、Ｂに関しては統合前のものに余り修正を加える必要が無く、ＣＡＮドライバ２５にのみ特徴的な修正を加えることでアプリケーションプログラム間の通信を実現することができる。また、内部バスを用いる必要が無く、メモリ上に設定されたバッファやフラグを用いてアプリケーションプログラム間の通信を行うため、アプリケーションプログラム間の通信を低コストで実現することができる。
【００８７】
更に、本実施例の情報処理装置１では、受信識別子テーブル３６を用いてＣＡＮドライバ２５が受信アプリの判別を行うため、上位層の通信ミドルウエアが受信可否の判別をする必要が無く、上位層のソフトウエア負荷を軽減することができる。
【００８８】
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【符号の説明】
【００８９】
１ 情報処理装置
１０ ＣＰＵ
２０ プログラムメモリ
２１ アプリケーションプログラムＡ
２２ アプリケーションプログラムＢ
２３ 通信ミドルウエアＡ
２４ 通信ミドルウエアＢ
２５ ＣＡＮドライバ
２５Ａ アプリＡ用インターフェース部
２５Ｂ アプリＢ用インターフェース部
２５Ｃ 共通処理部
３０ 主記憶装置
３１ 送信ＰＤＵバッファＡ
３２ 送信ＰＤＵバッファＢ
３３ 送信ＰＤＵフラグＡ
３４ 送信ＰＤＵフラグＢ
３５ 受信ＰＤＵバッファ
３６ 受信識別子テーブル
４０ ＣＡＮコントローラ
５０ ＣＡＮトランシーバ
６０ 周辺Ｉ／Ｏ
７０ 周辺機器
【特許請求の範囲】
【請求項１】
外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、
前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、
前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、
前記コントローラを制御するドライバと、を備え、
前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、
前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、
情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記外部機器との通信に用いられる送信バッファ及び受信バッファを備え、
前記複数のアプリケーションプログラム間の通信は、前記複数のアプリケーションプログラムのうち送信側のアプリケーションプログラムの指示により前記送信バッファに書き込まれたデータを、前記ドライバが前記受信バッファにコピーし、前記ドライバが前記複数のアプリケーションプログラムのうち受信側のアプリケーションプログラムに受信通知を行うことによって実行される、
情報処理装置。
【請求項３】
請求項２に記載の情報処理装置であって、
受信識別子と受信対象の関係を規定したテーブルを備え、
前記ドライバは、前記送信バッファに書き込まれたデータに含まれる受信識別子を用いて前記テーブルを検索することにより、前記受信側のアプリケーションプログラムを特定する、
情報処理装置。
【請求項１】
外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、
前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、
前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、
前記コントローラを制御するドライバと、を備え、
前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、
前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、
情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記外部機器との通信に用いられる送信バッファ及び受信バッファを備え、
前記複数のアプリケーションプログラム間の通信は、前記複数のアプリケーションプログラムのうち送信側のアプリケーションプログラムの指示により前記送信バッファに書き込まれたデータを、前記ドライバが前記受信バッファにコピーし、前記ドライバが前記複数のアプリケーションプログラムのうち受信側のアプリケーションプログラムに受信通知を行うことによって実行される、
情報処理装置。
【請求項３】
請求項２に記載の情報処理装置であって、
受信識別子と受信対象の関係を規定したテーブルを備え、
前記ドライバは、前記送信バッファに書き込まれたデータに含まれる受信識別子を用いて前記テーブルを検索することにより、前記受信側のアプリケーションプログラムを特定する、
情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−６２７３４（Ｐ２０１３−６２７３４Ａ）
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願番号】特願２０１１−２００７７９（Ｐ２０１１−２００７７９）
【出願日】平成２３年９月１４日（２０１１．９．１４）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願日】平成２３年９月１４日（２０１１．９．１４）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]