【発明の詳細な説明】 【０００１】 【発明の属する技術分野】電子制御装置等に関する。 【０００２】 【従来の技術】従来より、データ送信機能を備えた電子制御装置において、送信先の装置にデータを送信する場合に、データの送信後、所定時間は次のデータを送信しないように制御するものがある。 【０００３】例えば図１に示すように、バス１０Ａに接続されたＥＣＵ２０ＡとＥＣＵ２０Ｂと、バス１０Ｂに接続されたＥＣＵ２０Ｃと、バス１０Ａとバス１０Ｂの双方に接続されたゲートウェイＥＣＵ３０を備えるシステムにおいて、ゲートウェイＥＣＵ３０がバス１０Ａやバス１０Ｂに送信されたフレームの宛先に応じて、バス１０Ａとバス１０Ｂの間のフレームの中継を行うシステムがある。 例えばゲートウェイＥＣＵ３０は、ＥＣＵ２
０ＡがＥＣＵ２０Ｂ宛のフレームをバス１０Ａに送信した場合には、そのフレームのバス１０Ｂへの中継を行わず（図１の経路参照）、ＥＣＵ２０ＡがＥＣＵ２０Ｃ
宛のフレームをバス１０Ａへ送信した場合には、そのフレームをバス１０Ａから受信して、バス１０Ｂへ中継する（図１の経路参照）。 このようにゲートウェイＥＣ
Ｕ３０はバスに送信されたフレームを受信し、別のバスにフレームを中継するかを判断して、中継する場合には中継先のバスにフレームを送信する処理を行う。 したがってゲートウェイＥＣＵ３０においては受信・判断・送信等の処理を行う必要があり、バス間を中継するのに所定の時間を要する。 そのため、フレームを送信する側のＥＣＵ１０Ａでは、フレームの送信後、所定の時間は同じフレームをバス１０Ａに送信しないように制御する。 【０００４】このような制御は、図２（ａ）に示すように、フレームの送信後に送信を禁止する時間（遅延したい時間、すなわち遅延時間）が経過したか否かを判定し、遅延したい時間分経過した場合にのみ送信を可能とすることで実現している。 【０００５】 【発明が解決しようとする課題】しかしながら、例えば、外部からのノイズ等の影響によるＥＣＵの異常や、
タイマを構成するハードウェアまたはソフトウェアの異常等により、上記遅延時間を計測するタイマに異常が生じ、図２に示すようにタイマ値が遅延したい時間より短い時間になってしまう可能性がある。 【０００６】このように種々の要因によりタイマ値が異常となり、遅延したい時間よりも短い値になってしまうと、送信遅延したい時間が経過しなくても送信が可能となってしまう。 例えば図１のＥＣＵ２０Ａでこのようなタイマの異常が発生した場合、遅延時間が経過していないのにデータがバス１０Ａに送信されるため、ゲートウェイＥＣＵ３０の受信・判断・送信等の処理が間に合わなかったり、ゲートウェイＥＣＵのフレームの宛先毎の受信バッファが足りなくなったり、受信バッファに上書されてしまうなどして、正常にフレームを中継できなくなる可能性がある。 また、図１の例に限らず、このように送信遅延を行う必要のある種々の電子制御装置において、同様の問題が発生するおそれがある。 【０００７】そこで本発明は、送信遅延時間の保証をより確実に行うことのできる電子制御装置を提供することを目的とする。 【０００８】 【課題を解決するための手段及び発明の効果】上述した問題点を解決するためになされた請求項１に記載の電子制御装置によれば、複数のタイマのうち、本来所定時間に達していないにもかかわらず、所定時間経過を示す状態となった場合となるタイマがあったとしても、いずれか１のタイマが正常であれば、送信が禁止されるため、
所定時間（遅延時間）経過前にデータが送信されることがない。 【０００９】例えば２つのタイマを備える場合、第１のタイマの値が何らかの要因により異常な値となり、本来所定時間に達していないにもかかわらず、所定時間経過を示す状態となった場合であっても、第２のタイマが正常であれば、送信が禁止されるため、所定時間（遅延時間）経過前にデータが送信されることがない。 逆に第２
のタイマの値が異常な値となった場合も、第１のタイマが正常であれば、所定時間（遅延時間）の間は送信が禁止されるため、遅延時間経過前にデータが送信されることがない。 【００１０】このようにいずれか一つのタイマに異常が生じても、遅延時間の間はデータの送信を禁止することができ、送信遅延時間の保証を確実に行うことができる。 なお、これらのタイマはハードウェアで構成してもソフトウェアで構成してもよい。 【００１１】また、請求項２に示すようにタイマが前記所定時間に達したことを示し、かつ、フラグがロック状態でない場合に所定時間経過したと判断するとよい。 このようにすれば、例えばタイマが異常となり遅延時間経過していないにもかかわらず遅延時間経過を示す値になった場合であっても、ロック機構が正常であれば送信可能状態にならない。 したがって送信遅延時間の保証を確実に行うことができる。 【００１２】こうした電子制御装置には、バッファに書き込まれた送信対象のデータを送信するものがある。 このような装置では、請求項３のようにするとよい。 こうすることで送信遅延中はバッファの書き換えを禁止することができる、よって、例えばアプリケーションプログラムによる処理で送信データをバッファに書き込み、ミドルウェアによる処理でバッファに書き込まれたデータを送信するような送信データの生成と、データの送信を別の機構で行う構成の場合に、アプリケーションプログラムによる処理で、送信遅延時間が経過しないにもかかわらずデータをバッファへ書き込んでしまい、書き換えられたバッファのデータをミドルウェアが送信してしまうことを防止することができる。 すなわちバッファへの書き込み後、バッファのデータが書き込んだデータになったか否かを判定することでアプリケーションプログラムは送信可能だったか否かを判定することができ、ミドルウェアは、バッファにデータが書き込まれたか否かから送信するか否かを判定することができる。 また、たとえ送信遅延時間が経過していないにもかかわらず送信可能状態になったとしても、バッファのデータに変化がないので、ミドルウェアは同一のデータを再送するにとどまる。 なお、もちろん送信中もバッファの書き換えを禁止するとよい。 【００１３】そして、請求項１〜３のいずれかに記載の機能は、請求項４に示すように、例えば、電子制御装置のコンピュータシステムで実行するプログラムとして備えることができる。 このようなプログラムの場合、例えば、フレキシブルディスク、光磁気ディスク、ＣＤ−Ｒ
ＯＭ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータシステムにロードして起動することにより用いることができる。 また、ネットワークを介してロードして起動することにより用いることもできる。 【００１４】 【発明の実施の形態】以下、本発明が適用された実施例について図面を用いて説明する。 なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。 【００１５】図１は実施例の電子制御装置であるＥＣＵ
２０（ＥＣＵ２０Ａ〜２０Ｃ）を含む車両制御システムの構成を示すブロック図である。 ＥＣＵ２０は、ＣＰ
Ｕ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏ，タイマ等を備え、ＲＯＭ
やＲＡＭに記憶されたプログラム及びデータに基づいてＣＰＵが所定の処理を行い所定の機能を実現する。 例えば、センサ等からの信号を入力し、制御対象となる装置を制御する機能を備える。 またＥＣＵ２０Ａ及びＥＣＵ
２０Ｂはバス１０Ａに接続され、ＥＣＵ２０Ｃはバス１
０Ｂに接続されている。 【００１６】ゲートウェイＥＣＵ３０は、ＥＣＵ２０と同様にＣＰＵ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏ等を備え、バス１０Ａとバス１０Ｂに接続されている。 そしてゲートウェイＥＣＵ３０は、バス１０Ａに送信されるデータのうち、バス１０Ｂに接続されたＥＣＵ２０を宛先とするデータをバス１０Ｂに中継する機能を備える。 また、逆にバス１０Ｂに送信されるデータのうち、バス１０Ａに接続されたＥＣＵ２０を宛先とするデータをバス１０Ａに中継する機能を備える。 【００１７】例えば、ＥＣＵ２０ＡがＥＣＵ２０Ｃ宛のデータをバス１０Ａに送信した場合には、ゲートウェイＥＣＵ３０は、バス１０Ａ上のデータを受信し、バス１
０Ａに送信されたデータの宛先がバス１０Ａに接続されたＥＣＵ２０に対するものなのか、またはバス１０Ｂに接続されたＥＣＵ２０に対するものなのかを判定して、
バス１０Ｂに接続されたＥＣＵ２０宛のデータである場合には、バス１０Ｂへそのデータを送信する中継処理を行う。 この中継処理によって、ＥＣＵ２０Ａから送信されたＥＣＵ２０Ｃ宛のデータは、バス１０Ａからバス１
０Ｂに中継される。 【００１８】そして、この中継処理には所定の時間を要するため、送信元のそれぞれのＥＣＵ２０では、バス１
０へのデータの送信後、所定の時間が経過するまでは、
同一フレームの送信を行わないようにする。 このようなＥＣＵ２０での送信処理を図３及び図４を参照して説明する。 【００１９】ＥＣＵ２０での送信処理は、アプリが送信データの書き込み要求をミドルウェアに対して渡し、ミドルウェアがその要求に応じて送信処理を行うように構成されている。 なお、ここで「アプリ」及び「ミドルウェア」は、実際にはそれぞれのプログラムに基づくＥＣ
Ｕ２０の処理である。 【００２０】図３（ａ）に示すように、アプリからのデータの書き込み要求（メッセージの送信）が、送信処理を行うミドルウェアに対してあった場合に、ミドルウェアは受け取ったメッセージのメッセージＩＤに対応するＲＡＭ上のメッセージバッファにそのメッセージに含まれるデータを書き込み、メッセージＩＤ毎に設けたステータスの値を設定する。 このステータスには、「送信中ロック」と「送信遅延ロック」が含まれ、これらは１ビットのフラグとしてそれぞれ管理される。 フラグの値が「１」の場合にはロック中を示し、「０」の場合にはアンロック中を示す。 またメッセージＩＤはメッセージ毎に異なるものを利用している。 【００２１】そして、図３（ｂ）に示すように、上記ステータスがロック中であるか否かと、送信後の経過時間をカウントするタイマの値に基づいて、データが送信可能か否かを判定し、送信可能な場合にデータをバス１０
へ送信する処理を行う。 この処理の具体的な内容を図４
のフローチャートに示して説明する。 【００２２】ミドルウェアは、書き込まれたメッセージを定期的に送信（定期送信）するのか、メッセージ書き込み後すぐに送信するのかを、アプリからの指示に基づき予めメッセージＩＤ毎に設定しておく。 そしてこのメッセージＩＤ毎の送信タイミングの設定に基づき、
定期送信のメッセージＩＤのデータについては、タイマの値が所定時間経過する毎に図４のＳ１２０から処理を実行する処理を行う。 一方、書き込み後すぐに送信するメッセージＩＤのデータがアプリから書き込まれた場合には、Ｓ１１０から処理を開始する。 なおこのタイマはハードウェアでフリーランカウントする。 【００２３】Ｓ１１０では、アプリから受け取ったメッセージのメッセージＩＤに対応するメッセージバッファに、メッセージに含まれるデータを記憶する。 例えば、
メッセージＩＤが０のデータは図３（ａ）のメッセージバッファの「メッセージ０」の領域内に記憶される。 【００２４】Ｓ１２０では、メッセージＩＤに対応するステータスの送信中ロックフラグが０か否かを判定し、
０の場合には（Ｓ１２０：ＹＥＳ）、Ｓ１３０へ移行し、１の場合には（Ｓ１２０：ＮＯ）、０になるまでＳ
１２０を実行する。 Ｓ１３０では、メッセージＩＤに対応するステータスの送信遅延ロックフラグが０か否かを判定し、０の場合には（Ｓ１３０：ＹＥＳ）Ｓ１４０へ移行し、１の場合には（Ｓ１３０：ＮＯ）、Ｓ１２０へ戻る。 【００２５】Ｓ１４０では、前回の送信時にＳ１７０で記憶したタイマ値と現在のタイマ値との差分を求め、前回の送信から送信遅延時間分以上経過したか否かを判定し、経過した場合には（Ｓ１４０：ＹＥＳ）Ｓ１５０へ移行し、経過していない場合には（Ｓ１４０：ＮＯ）Ｓ
１２０へ戻る。 【００２６】Ｓ１５０では、メッセージＩＤに対応するステータスの送信中ロックフラグを「１」にセットする。 Ｓ１６０では、メッセージＩＤに対応するメッセージバッファに記憶されたデータを送信する。 【００２７】送信が完了するとＳ１７０で、現在のタイマ値をメッセージＩＤに対応付けて記憶し、送信遅延ロックのフラグを１とし、送信中ロックを０に戻す。 また以上の処理とは別に、メッセージＩＤ毎に設けたダウンカウンタを用いて、送信遅延ロックがセットされた後、
所定時間経過した際に送信遅延ロックをリセットする（０にする）処理を行う。 【００２８】図５にこの処理のフローチャートを示す。
この処理は、所定時間毎に起動され、すべてのメッセージＩＤについて行われる。 Ｓ３１０では、送信遅延ロックが０から１に変化したか否かを判定する。 送信遅延ロックが１になった場合には（Ｓ３１０：ＹＥＳ）、Ｓ３
２０へ移行し、それ以外の場合には（Ｓ３１０：Ｎ
Ｏ）、Ｓ３３０へ移行する。 【００２９】Ｓ３２０では、送信遅延時間に相当するダウンカウンタ値を設定する。 Ｓ３３０では、ダウンカウンタをディクリメントする。 Ｓ３４０では、ダウンカウンタが０か否かを判定する。 ダウンカウンタが０の場合には（Ｓ３４０：ＹＥＳ）Ｓ３５０へ移行し、ダウンカウンタが０でない場合には（Ｓ３４０：ＮＯ）、そのメッセージＩＤに対応する処理を終了し、次のメッセージＩＤがある場合には、次のメッセージＩＤに関して同様にＳ３１０から処理を行う。 【００３０】このように、従来のタイマとは別にダウンカウンタを設けることで、送信遅延をより確実に行うことができる。 すなわち、図６に示すように、図４のＳ１
４０で判定するタイマによる送信遅延時間が、何らかの要因によって異常となったとしても、Ｓ１７０で送信完了後に設定される送信遅延ロックによって、Ｓ１３０の判定処理により、この送信遅延ロックが解除されるまでは、Ｓ１６０の送信処理を行わない。 送信遅延ロックが解除されるのは、図５に示した処理により所定時間毎にディクリメントされるダウンカウンタが０になった場合であり、このダウンカウンタは、送信遅延時間に相当する値である。 したがって、図６に示すようにタイマ値が異常となっても送信遅延時間が経過するまではロック機構により送信がなされない。 ダウンカウンタとタイマの双方が同時に異常となる確率は一方が異常になる確率より低いので、より確実に送信遅延時間を保証することができる。 なお、図４のＳ１５０、Ｓ１７０とＳ１２０の送信中ロックに関する処理により、送信中に再度送信してしまうことも防止することができる。 【００３１】なお、上記実施例において図４の送信処理の際に、送信中及び送信遅延中にはメッセージバッファへの書き込みを禁止するようにしてもよい。 すなわち、
図７に示すように、アプリからのメッセージを受け取ったミドルウェアは、図４のＳ１１０〜Ｓ１７０の処理に先立って、Ｓ１０２及びＳ１０３の処理を実行するようにする。 このＳ１０２では、送信中ロックが０であるか否かを判定し、０の場合には（Ｓ１０２：ＹＥＳ）、Ｓ
１０４へ移行し、１の場合には（Ｓ１０２：ＮＯ）０になるまでＳ１０２を実行する。 Ｓ１０４では、送信遅延ロックが０であるか否かを判定し、０の場合には（Ｓ１
０２：ＹＥＳ）、Ｓ１１０へ移行し、１の場合には（Ｓ
１０４：ＮＯ）、Ｓ１０２へ戻る。 したがって、送信中及び送信遅延時間中はバッファへのデータの書き込み（Ｓ１１０の処理）は行われない。 こうして、送信中及び送信遅延時間中はバッファへのデータの書き込みを防止することができる。 【００３２】上記実施例においては、メッセージＩＤ毎に設けたダウンカウンタを用いて送信遅延ロックの制御を行ったが、例えばその他のタイマ等を用いてこのロックの制御を行うようにしてもよい。 またタイマはソフトウェアで構成してもハードウェアで構成してもよい。 また上記実施例では、送信遅延時間は固定としたが、例えばメッセージＩＤ毎に設定できるようにしてもよい。 また、上記実施例のようにメッセージＩＤ毎のステータスを設け、送信の管理を行うのではなく、ＥＣＵ全体として１つのステータスを設け送信遅延時間を管理する場合にも図４、図５に示した処理を適用できる。 【００３３】そして上記実施例ではミドルウェアとアプリから構成される処理として説明したがこれに限らす種々のソフトウェア構成のシステムに適用することができる。 また、上記実施例では、バス１０へデータを送信するＥＣＵ２０の処理として説明したが、このような送信遅延（送信後所定時間は送信を行わない）処理を行うシステムであれば、どのようなシステムにも適用することができる。 【００３４】なお、本実施例において、タイマが請求項１におけるタイマに相当し請求項２におけるタイマに相当する。 そしてダウンカウンタが請求項１におけるタイマに相当し、請求項２における「別にカウント」をするためのカウンタに相当する。 また、送信遅延ロックフラグがフラグに相当する。

【図面の簡単な説明】 【図１】実施例の電子制御装置を含むシステムの構成を示す図である。 【図２】従来の送信遅延の方法と問題点を示す説明図である。 【図３】ミドルウェアの構成を示す説明図である。 【図４】ミドルウェアの送信処理のフローチャートである。 【図５】ミドルウェアのダウンカウンタ管理処理のフローチャートである。 【図６】実施例の送信遅延の方法を示す説明図である。 【図７】送信中及び送信遅延期間中にバッファへの書き込みを禁止する処理を付加した送信処理のフローチャートである。 【符号の説明】 １０Ａ，１０Ｂ…バス２０Ａ，２０Ｂ…ＥＣＵ ３０…ゲートウェイＥＣＵ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 古田 克彦 愛知県刈谷市昭和町１丁目１番地 株式会 社デンソー内(72)発明者 岡田 稔 愛知県刈谷市昭和町１丁目１番地 株式会 社デンソー内Ｆターム(参考） 5K033 CB08 DA05 DB13 DB19 EC03