(57)【要約】【課題】データの送信サイズと蓄積サイズとの不整合によるオーバーフローの発生を検知できるようにして、データの連続性の確保を可能とする。【解決手段】ポンプコントローラ１は、１６６．６μｓの割り込み周期毎に４Byteのデータをバッファ１１に格納し、５msの送信周期毎に３０回分の１２０Byteのデータを外部のモニタツール４に送信する。ここで、１６６．６μｓ×３０＝４９９８μｓと、送信周期とのずれに因って、３１回目の割り込みが生じることで、送信されずにバッファ１１内に残るデータが蓄積される。そこで、送信直前の状態でバッファ１１に全容量分の２５６Byteのデータが格納されている場合には、バッファ１１に格納されている全データを消去し、かつ、次回送信時にデータの識別子に設定値を付加することで、データ消去によるデータ欠落が生じていることを、モニタツール４に通知する。【選択図】図５
2013192176.tif 000002
【特許請求の範囲】
【請求項１】
割り込み周期毎にデータを一定容量ずつバッファに格納し、送信周期毎に、前記割り込み周期の複数回分に相当する容量のデータを前記バッファから取得順に読み出して外部に送信する自動車用電子制御装置であって、
前記バッファのオーバーフローが生じるときに、前記バッファ内のデータを消去する、自動車用電子制御装置。
【請求項２】
前記バッファ内のデータを消去することによる送信データの欠落を、データフレームの識別子によって外部に通知する、請求項１記載の自動車用電子制御装置。
【請求項３】
前記バッファを介してデータが送信される外部装置が、前記自動車用電子制御装置の動作確認を行うためのモニタツールである、請求項１又は２記載の自動車用電子制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バッファを介してデータを外部に送信する自動車用電子制御装置に関する。
【背景技術】
【０００２】
特許文献１には、ＣＡＮ（Controller Area Network）モジュールとして、送信するメッセージ及び受信したメッセージを複数バッファ可能なメッセージバッファと、メッセージバッファ上の更新が行われたバッファの位置を示す履歴情報を所定回数分格納可能なリングバッファと、メッセージバッファ上のメッセージ管理を行うメッセージハンドリング部とを備えたものが開示されている。
また、特許文献１には、リングバッファの空き領域が無くなった場合にフラグをセットし、更にデータを受信した場合、古いデータを保護するために、書き込みポインタから１つ戻ったポインタ位置に受信したデータを格納し続けることが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２２２６２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、自動車用電子制御装置においては、当該制御装置内のデータをバッファに一旦蓄積し、外部のモニタツールなどに対して、バッファに格納したデータをまとめてＣＡＮ通信などによって送信する場合がある。
しかし、データを外部へ送信する周期が、データをバッファに格納する周期の整数倍でない場合、データの送信サイズと蓄積サイズとが不整合となって、送信できなかったデータがバッファ内に蓄積していって、バッファがオーバーフローする場合があった。
そして、一旦オーバーフローが発生してしまうと、送信できないデータが短周期で発生するようになり、外部のモニタツールが監視するデータの連続性が大きく損なわれてしまい、動作確認などが精度良く行えなくなってしまうという問題が生じる。
【０００５】
本発明は上記問題点に鑑みなされたものであり、データの送信サイズと蓄積サイズとの不整合によるオーバーフローの発生を検知できるようにして、データの連続性の確保を可能とすることを目的とする。
【課題を解決するための手段】
【０００６】
そのため、本願発明では、割り込み周期毎にデータを一定容量ずつバッファに格納し、送信周期毎に、前記割り込み周期の複数回分に相当する容量のデータを前記バッファから取得順に読み出して外部に送信する自動車用電子制御装置であって、前記バッファがオーバーフローするときに、前記バッファ内のデータを消去するようにした。
【発明の効果】
【０００７】
上記発明によると、オーバーフローが発生したときに、バッファ内のデータを消去するので、送信できなかったデータがバッファ内に蓄積していって再度オーバーフロー状態になるまでの間で、送信データの連続性を確保できる。
【図面の簡単な説明】
【０００８】
【図１】本願発明の実施形態における自動車用電子制御装置のシステムブロック図である。
【図２】本願発明の実施形態におけるバッファへのデータ格納処理及びバッファからのデータ送信処理を説明するための概念図である。
【図３】本願発明の実施形態において３１回目の割り込みが発生する様子を説明するための図である。
【図４】本願発明の実施形態において送信されないデータが蓄積される様子を説明するための図である。
【図５】本願発明の実施形態におけるデータ送信処理及びバッファの消去処理を示すフローチャートである。
【図６】本願発明の実施形態における識別子の変化を示すタイムチャートである。
【発明を実施するための形態】
【０００９】
以下に本発明の実施の形態を説明する。
図１は、自動車用電子制御装置の一例としてのポンプコントローラ１を示している。
ポンプコントローラ１は、自動車２０に搭載される自動変速機などにオイルを供給するオイルポンプ２を駆動する制御ユニットである。
【００１０】
ポンプコントローラ１は、ＣＰＵ、ＲＯＭなどを含むコンピュータ（マイコン）１０を備えると共に、ＣＡＮ通信線３を介して外部のモニタツール４や他の車載制御装置５との間で通信を行う場合に、データを一時的に保存する記憶装置又は記憶領域であるリングバッファなどのバッファ１１を備えている。
モニタツール４は、ポンプコントローラ１などのＣＡＮ通信線３に接続されている各種の制御装置の動作確認を行う場合にＣＡＮ通信線３に接続される、診断用ツールである。モニタツール４は、例えば、コンピュータ、表示装置、及び、キーボードなどのマンマシンインタフェースを含む装置であり、一例として市販のパーソナルコンピュータを用いることができる。
【００１１】
ここで、ポンプコントローラ１が、ポンプコントローラ１の動作確認などを行うモニタツール４に対してデータ（内部演算データ）を送信する場合の通信処理の詳細を例示する。
図２に示すように、バッファ１１は、２５６Byteの容量を有し、ポンプコントローラ１は、１６６．６μｓ毎の割り込み処理によって、１割り込み当たり４Byteのデータ（送信用データ）をバッファ１１に格納する。そして、ポンプコントローラ１は、送信周期である５ｍｓ毎に、バッファ１１内に格納されている１２０Byteのデータを取得順に従ってまとめてモニタツール４に送信する。
【００１２】
即ち、割り込みが３０回発生する毎に、３０回の割り込み処理で合計が１２０Byte（４Byte×３０回＝１２０Byte）になっているバッファ１１内の格納データを、ＣＡＮ通信線３を介してモニタツール４に送信するようにしてある。
但し、１６６．６μｓの割り込み周期の３０回分は、１６６．６μｓ×３０回＝４９９８μｓとなり、送信周期の５msに一致しないので、図３に示すように、３０回目の割り込みタイミングと、データ送信を行う５ｍｓのタイミングとの間にずれが生じる。
【００１３】
上記の３０回目の割り込みタイミングと、データ送信を行う５ｍｓのタイミングとの間におけるずれは、当初は２μｓであるものの、このずれた位置から再度３０回の割り込みを開始するために、データ送信を行う毎に徐々に拡大していく。そして、ずれ時間が１６６．６μｓ以上になると、データ送信の周期である５ｍｓの間に３１回の割り込みが生じ、その結果、５ｍｓの間に１２４Byte（４Byte×３１回＝１２４Byte）のデータがバッファ１１に格納されることになる。
【００１４】
しかし、バッファ１１からは、図４（Ａ）に示すように、３０回の割り込みによってバッファ１１に格納される１２０Byteのデータが５ｍｓ毎に送信されるようになっている。このため、図４（Ｂ）に示すように、１回目から３０回目までの割り込みで格納された１２０Byteのデータは、モニタツール４に送信されることになるが、３１回目（最後）の割り込みで格納した４Byteのデータは、送信されずにバッファ１１内に残ることになる。
【００１５】
そして、図４（Ｃ）に示すように、４Byteのデータが残った状態のまま、再度、３０回の割り込みによる１２０Byteデータがバッファ１１に格納されるから、５ｍｓ毎の送信周期になったときには、また、バッファ１１に１２４Byteのデータが格納されている状態になり、４Byteのデータが残る状態は解消されない。
尚、前回の送信時に、バッファ１１に残された４Byteのデータは、次の送信周期では、最も古いデータとなるので、送信される１２０Byteに含まれ、最新に格納された４Byteのデータがバッファ１１に残されることになるので、送信されるデータの連続性は保持される。
【００１６】
そして、前記ずれ時間が１６６．６μｓ以上に再度なると、それまで残されていたデータに加えて、３１回分の１２４Byteのデータがバッファ１１に格納されることになり、結果、バッファ１１に残されるデータが更に４Byteだけ増えることになり、以後、３１回目のデータが格納される毎に、バッファ１１に残されるデータが４Byteずつ増えていくことになる。
上記のようにして、送信周期である５ｍｓの間に３１回の割り込みがなされる毎に、１２０Byteのデータを送信してもバッファ１１内の残されることになるデータの容量が４Byteずつ増えていき、最終的には、図４（Ｄ）に示すように、５ｍｓ毎の送信タイミングにおいてバッファ１１の全容量分に相当する２５６Byteのデータが格納される状態となり、１２０Byteのデータを送信してもバッファ１１内に１３６Byteが残される状態となる。
【００１７】
バッファ１１内に１３６Byteのデータが残される状態では、バッファ１１に１２０Byteの空き容量しかないから、次に送信周期の間に３１回の割り込みが行われると、３１回目の４Byteのデータをバッファ１１に格納することができず、バッファ１１のオーバーフロー状態になってしまう。
尚、上記の割り込み周期＝１６６．６μｓ、送信周期＝５ｍｓ、割り込み処理１回当たりの格納データサイズ＝４Byte、送信データサイズ＝１２０Byte、バッファ容量＝２５６Byteは一例であり、上記の設定に限定されるものではない。そして、バッファ１１のオーバーフローは、（送信データサイズ／格納データサイズ）×割り込み周期が、送信周期よりも短いこと、換言すれば、バッファ１１へのデータの格納周期である割り込み周期を整数倍した場合に、送信周期に一致しないことにより生じる。
【００１８】
バッファ１１がオーバーフローすると、例えば、リングバッファの場合、バッファ１１に格納したデータのうちで最も古いデータが最新データによって上書きされ、上書きで消されたデータはモニタツール４に送信されないことになり、係る送信データの欠落によって、モニタツール４が受け取るデータの連続性が損なわれる。
そして、バッファ１１を介してデータを受信するモニタツール４では、バッファ１１のオーバーフローによる受信データの不連続な変化を、例えば、ポンプコントローラ１の動作不良に因るものと誤判断してしまう可能性がある。
【００１９】
そこで、ポンプコントローラ１は、図５のフローチャートに示すようにして、バッファ１１の格納データの消去する処理を行うようにしてある。
図５のフローチャートに示す処理は、データ送信周期の５ｍｓ毎に割り込み実行され、まず、ステップＳ１０１では、１２０Byteのデータを送信する直前の状態において、バッファ１１に全容量分の２５６Byteのデータが格納されているか否かを判断する。
【００２０】
全容量分の２５６Byteのデータが格納されている状態とは、今回１２０Byteのデータを送信しても、１３６Byteのデータがバッファ１１に残る状態であり、次に３１回目のデータを格納しようとしたときに、バッファ１１に空き容量がなく、オーバーフローによって上書きが実行されることになる状態である。
バッファ１１において送信されずに残るデータが１３２Byteである間は、３０回分の１２０Byteのデータを格納しても、空き容量が４Byte（４Byte＝２５６Byte−（１３２Byte＋１２０Byte）だけ残ることになる。
【００２１】
しかし、送信周期（５ｍｓ）の間に３１回目のデータが格納されると、直近の送信周期の間に格納されるデータサイズが１２４Byteになり、前回送信時に残った１３２Byteデータと合わせると、バッファ１１の全容量である２５６Byteになる。
従って、ステップＳ１０１において、バッファ１１に全容量分の２５６Byteのデータが格納されていると判断されるのは、直近の送信周期の間に３１回のデータ格納がなされ、かつ、前回送信時に１３２Byteのデータが送信されずに残っていた場合である。
【００２２】
バッファ１１に、全容量分の２５６Byteのデータが格納されていない場合、換言すれば、４Byte以上の空き容量がある場合には、今回１２０Byteのデータを送信すれば、空き容量が１２４Byte以上確保されることになり、３１回目の割り込みが行われるとしても、係る割り込みによるデータの格納を実施でき、バッファ１１はオーバーフロー状態にはならない。
そこで、ステップＳ１０１で、バッファ１１に全容量分の２５６Byteのデータが格納されておらず、空き容量がある場合には、ステップＳ１０２へ進み、バッファ１１に格納されているデータのうちで古い１２０Byte分のデータを、取得順に従ってモニタツール４に送信する。
【００２３】
ここで、１２０Byteよりも格納データのサイズが多い場合には、多い分のデータだけ送信されずにバッファ１１内に残り、次回の送信タイミングで送信されることになる。
一方、バッファ１１に全容量分の２５６Byteのデータが格納されている場合には、ステップＳ１０３へ進んで、バッファ１１に格納されている２５６Byteのデータを全て消去し、バッファ１１を送信されずに残されるデータがない初期状態に戻す。
【００２４】
これにより、再度、バッファ１１に全容量分の２５６Byteのデータが格納されるようになるまでは、連続性を保ってデータをモニタツール４に送信することができる。換言すれば、バッファ１１に全容量分の２５６Byteのデータが格納される毎に、データの消去を行い、係る消去が実施される周期の間では、データが連続的に送信されるようにしてある。
本実施形態で例示した、周期、データサイズの場合、バッファ１１の全容量分のデータが消去されるのは、１４．７秒毎になる。
【００２５】
モニタツール４における動作確認においては、一般的に、１０秒程度の連続したデータを取得できれば、動作確認に必要十分である。従って、バッファ１１に全容量分の２５６Byteのデータが格納される毎にデータを消去しても、消去直後の１４．７秒間で、高い精度で動作確認を行える。
但し、モニタツール４が、２５６Byte分の未送信データが消去されたこと、換言すれば、２５６Byte分のデータが欠落したことを認識しないと、消去タイミングを含む期間でデータを監視し、例えば、消去タイミングの前後でデータが急変したことに基づき、ポンプコントローラ１の動作不良を判定してしまう可能性がある。
【００２６】
そこで、ステップＳ１０４では、次のデータ送信タイミング（５ｍｓ経過後）において、１２０Byteのデータを送信するときのデータフレームに含まれる識別子ＩＤを、通常（消去タイミング直後でない場合）とは異なる値とする設定を行うことで、データ欠落の発生をモニタツール４側に通知する。
係る識別子ＩＤを付加された１２０Byteのデータを受け取ったモニタツール４は、識別子ＩＤに基づき、消去タイミング直後であるか否か、換言すれば、２５６Byte分の未送信データの欠落後であるか否かを判断できる。従って、モニタツール４を用いた動作確認においては、消去タイミングを跨いでのデータ監視をキャンセルし、消去タイミング直後の送信データの連続性が確保される１４．７秒間内において送信データを監視して、ポンプコントローラ１の動作状態を判断することができる。
【００２７】
図６は、識別子ＩＤ（ＣＡＮ  ＩＤ）の一例を示すものであり、消去タイミング直後でない場合には、０ｘ０１から０ｘ０Ｆまでの識別子ＩＤを、各送信データに与えるのに対し、消去タイミング直後の識別子ＩＤの１周期においては、例えば、通常値＋０ｘ１０として、識別子ＩＤの値をシフトさせる。
これにより、識別子ＩＤの変化範囲が、消去タイミング直後では、０ｘ１１〜０ｘ１Ｆとなるのに対し、それ以外では、０ｘ０１〜０ｘ０Ｆとなるから、モニタツール４側では、０ｘ１１以上の識別子ＩＤであるか否かによって、消去タイミング（２５６Byte分のデータ欠落）直後であるか否かを判断できる。
【００２８】
以上、好ましい実施形態を具体的に説明したが、当業者であれば、種々の変形態様を採り得ることは自明である。
例えば、上記実施形態では、自動車用電子制御装置をポンプコントローラ１としたが、この他、自動車用エンジンにおける燃料噴射量などを制御するエンジンコントローラや、自動変速機を制御するＡＴコントローラなどにおいても、同様にデータ送信及びデータ消去を行わせることで、同様の作用、効果を得ることができる。
【００２９】
また、バッファ１１に格納されている全データを消去させるタイミングとして、上記実施形態では、データ送信直前での空き容量が０Byteのときとしたが、空き容量が４Byteや８Byteなどの設定値（４Byte×ｎ：ｎは自然数）以下になったときに、バッファ１１に格納されている全データを消去させたり、空き容量が０Byteであるのに更に割り込みによるデータ格納要求が発生してバッファ１１内で上書きを行ったときに、バッファ１１に格納されている全データを消去させたりすることができる。即ち、本願において、バッファのオーバーフローが生じるときには、空き容量が無くなったとき、空き容量が無くなりそうなとき、空き容量がなくバッファ内を上書きしたときを含む。
【００３０】
また、送信相手の外部装置とは、自動車用電子制御装置に対してＣＡＮ通信線３などの通信線を介して接続される装置であればよく、モニタツール４に限定されないが、少なくとも、一定周期毎のデータ欠落が許容される装置である。
また、データ転送に用いる規格はＣＡＮに限定されず、ＬＩＮ（Local Interconnect Network）などの他のネットワーク通信を用いることができる。
【００３１】
ここで、上記実施形態から把握し得る請求項以外の技術的思想について、以下に効果と共に記載する。
（イ）前記バッファ内のデータを全て消去することによる送信データの欠落を、データフレームの識別子に対して、設定値を付加する補正を行うことによって外部に通知する、請求項２記載の自動車用電子制御装置。
上記発明によると、識別子に設定値を付加することで、識別子の変化範囲を異ならせることができ、以って、送信データの欠落の有無を識別子に基づき判定して、データの連続性が確保される区間を特定できる。
【００３２】
（ロ）前記バッファにおける空き容量が０Byteになったときに、前記バッファ内のデータを全て消去する、請求項１〜３のいずれか１つに記載の自動車用電子制御装置。
上記発明によると、送信できずに残るデータが蓄積し、送信直前におけるバッファの空き容量が０Byteになると、一定期間内にバッファの上書き（オーバーフロー）が生じるものと判断し、バッファ内のデータを全て消去することで、データ送信後に送信されなかったデータが残らない初期状態に戻す。
【００３３】
（ハ）前記バッファにおける空き容量が設定値（設定値＞０Byte）以下になったときに、前記バッファ内のデータを全て消去する、請求項１〜３のいずれか１つに記載の自動車用電子制御装置。
上記発明によると、送信できずに残るデータが蓄積し、バッファにおける空き容量が設定値（設定値＞０Byte）以下になると、近々にバッファの上書き（オーバーフロー）が生じるものと判断し、バッファ内のデータを全て消去することで、データ送信後に送信されなかったデータが残らない初期状態に戻す。
【００３４】
（ニ）前記バッファ内において上書きが行われたときに、前記バッファ内のデータを全て消去する、請求項１〜３のいずれか１つに記載の自動車用電子制御装置。
上記発明によると、送信できずに残るデータが蓄積し、バッファにおける空き容量が０Byteになった状態で、更にデータ格納の要求が発生し、バッファ内の古いデータを上書きすることになった場合には、バッファ内のデータを全て消去することで、データ送信後に送信されなかったデータが残らない初期状態に戻す。
【符号の説明】
【００３５】
１…ポンプコントローラ、２…オイルポンプ、３…ＣＡＮ通信線、４…モニタツール、１０…コンピュータ、１１…バッファ
【図１】
2013192176.tif 000003
【図２】
2013192176.tif 000004
【図３】
2013192176.tif 000005
【図４】
2013192176.tif 000006
【図５】
2013192176.tif 000007
【図６】
2013192176.tif 000008