(57)【特許請求の範囲】
【請求項１】
荷重センサと、該荷重センサに双方向通信可能に接続された制御装置とを備え、
前記荷重センサは、
シートに加わる荷重に応じた荷重検知信号に基づき所定の演算周期ごとに荷重情報を取得するとともに、前記荷重検知信号と所定の故障検知閾値に相当する閾値信号との大小関係に基づいて故障情報を取得する第１の制御部と、
前記故障情報が故障有りの状態に切り替わることで、所定時間内における前記演算周期ごとの前記荷重情報を故障検知時荷重情報として記憶する荷重情報記憶部とを有し、
前記制御装置は、前記演算周期よりも長い所定の通信周期ごとに前記荷重情報及び前記故障情報を受信する第２の制御部を有し、該第２の制御部は、
前記故障情報が故障有りの状態を表すときに、前記荷重情報記憶部に記憶された前記所定時間内における前記演算周期ごとの前記故障検知時荷重情報を前記通信周期ごとに順次、受信して前記故障検知時荷重情報を再生する波形再生部と、
前記再生された前記故障検知時荷重情報に基づいて故障の有無を判定する故障判定部とを備えた、荷重検出装置。
【請求項２】
請求項１に記載の荷重検出装置において、
前記第２の制御部には、車両衝突の有無を検知する衝突検知センサの検知信号が入力されており、
前記第２の制御部は、前記故障判定部が故障有りと判定したとき、前記衝突検知センサの前記検知信号が車両衝突無しの状態を表すときに、前記故障判定部による故障有りの判定をキャンセルする判定キャンセル部を有した、荷重検出装置。
【請求項３】
請求項１又は２に記載の荷重検出装置において、
前記荷重情報記憶部は、前記所定時間の終期で前記荷重情報の記憶・更新が停止されるリングバッファである、荷重検出装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、荷重検出装置に関するものである。
【背景技術】
【０００２】
従来、荷重検出装置としては、例えば特許文献１に記載されたものが知られている。この荷重検出装置は、荷重センサと、該荷重センサに双方向通信可能に接続された制御装置（ＥＣＵ）とを備える。そして、荷重センサは、シート本体に加わる荷重に応じた荷重検知信号を出力する荷重検知素子と、荷重検知信号に基づき荷重情報を取得する第１の制御部（制御部）とを有する。第１の制御部は、荷重検知信号と所定の故障検知閾値に相当する閾値信号との大小関係に基づいて故障情報を併せて取得するように構成されている。これは、例えば荷重検知信号が過大となる際に、車両衝突など修理を要する現象（故障）が発生している可能性が高いことによる。
【０００３】
一方、制御装置は、荷重センサから荷重情報及び故障情報を受信する第２の制御部（ＣＰＵ）を有する。第２の制御部は、荷重情報に基づいて、例えばシートが空席状態か着席状態かの乗員の有無を判定する。あるいは、第２の制御部は、故障情報に基づいて、例えば修理を促すための報知をすべく、インジケータを駆動する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−３２３１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、特許文献１では、第２の制御部は、第１の制御部に依存する故障情報を受信して、該故障情報に合わせて所要の処理を行うのみである。これは、荷重情報を取得する第１の制御部の演算周期に比べて、荷重情報等を受信する第２の制御部の通信周期が著しく長く設定されており、故障情報を自身で取得し得るように第２の制御部の通信周期を短縮することは困難なためである。
【０００６】
一方、第１の制御部は、荷重検知信号と閾値信号との大小関係のみに基づいて故障情報を取得することから、その信頼性には自ずと限界がある。従って、例えば修理が不要であるにも関わらず、該修理を促す報知が第２の制御部によって徒に行われる可能性がある。
【０００７】
本発明の目的は、通信負荷を増加することなく、修理を促す報知の信頼性をより向上することができる荷重検出装置を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決する荷重検出装置は、荷重センサと、該荷重センサに双方向通信可能に接続された制御装置とを備え、前記荷重センサは、シートに加わる荷重に応じた荷重検知信号に基づき所定の演算周期ごとに荷重情報を取得するとともに、前記荷重検知信号と所定の故障検知閾値に相当する閾値信号との大小関係に基づいて故障情報を取得する第１の制御部と、前記故障情報が故障有りの状態に切り替わることで、所定時間内における前記演算周期ごとの前記荷重情報を故障検知時荷重情報として記憶する荷重情報記憶部とを有し、前記制御装置は、前記演算周期よりも長い所定の通信周期ごとに前記荷重情報及び前記故障情報を受信する第２の制御部を有し、該第２の制御部は、前記故障情報が故障有りの状態を表すときに、前記荷重情報記憶部に記憶された前記所定時間内における前記演算周期ごとの前記故障検知時荷重情報を前記通信周期ごとに順次、受信して前記故障検知時荷重情報を再生する波形再生部と、前記再生された前記故障検知時荷重情報に基づいて故障の有無を判定する故障判定部とを備える。
【０００９】
この構成によれば、前記第２の制御部は、前記波形再生部において、前記所定時間内における前記演算周期ごとの前記故障検知時荷重情報を受信・再生するとともに、前記故障判定部において、当該再生された前記故障検知時荷重情報に基づいて故障の有無を判定する。この場合、前記第２の制御部は、前記故障判定部における故障の有無の判定において、前記第１の制御部における前述の閾値判定に準じた閾値判定に加えて、例えば前記荷重情報が増加及び減少の一方から他方に切り替わるまでの経過時間やそれらの変動か収束するまでの経過時間といった前記故障検知時荷重情報の推移を利用することができる。このため、前記故障判定部における故障の有無の判定精度をより向上させることができる。そして、例えば前記故障判定部が故障有りと判定した際に前記第２の制御部が修理を促す適宜の報知をさせる場合には、当該報知の信頼性をより向上させることができる。一方、前記第２の制御部は、前記波形再生部において、前記荷重情報記憶部に記憶された前記所定時間内における前記演算周期ごとの前記故障検知時荷重情報を前記通信周期ごとに順次、受信すればよいため、通信負荷を増加しなくてもよい。
【００１０】
上記荷重検出装置について、前記第２の制御部には、車両衝突の有無を検知する衝突検知センサの検知信号が入力されており、前記第２の制御部は、前記故障判定部が故障有りと判定したとき、前記衝突検知センサの前記検知信号が車両衝突無しの状態を表すときに、前記故障判定部による故障有りの判定をキャンセルする判定キャンセル部を有することが好ましい。
【００１１】
この構成によれば、前記衝突検知センサの前記検知信号が車両衝突無しの状態を表すのであれば、前記判定キャンセル部により前記故障判定部による故障有りの判定がキャンセルされることで、前記報知の信頼性をいっそう向上させることができる。
【００１２】
上記荷重検出装置について、前記荷重情報記憶部は、前記所定時間の終期で前記荷重情報の記憶・更新が停止されるリングバッファであることが好ましい。
この構成によれば、前記リングバッファに対する前記演算周期ごとの前記荷重情報の記憶・更新は、記憶済みの前記荷重情報の中で最も古い前記荷重情報を書き換えるとともに、この段階で最も古くなる前記荷重情報が記憶される記憶領域を先頭の記憶領域に設定すればよいため、処理負荷をより軽減することができる。
【発明の効果】
【００１３】
本発明は、通信負荷を増加することなく、修理を促す報知の信頼性をより向上できる効果がある。
【図面の簡単な説明】
【００１４】
【図１】荷重検出装置の第１の実施形態が適用されるシートの骨格部についてその構造を示す側面図。
【図２】同実施形態の荷重検出装置についてその荷重センサの電気的構成を示すブロック図。
【図３】同実施形態の荷重検出装置についてそのＥＣＵの電気的構成を示すブロック図。
【図４】（ａ）〜（ｅ）は、それぞれ荷重検知電圧、バッファの記憶領域、故障検知ビット、再生波形データ及びＥＣＵの受信する荷重情報の時間的推移を示すタイムチャート。
【図５】同実施形態の荷重検出装置についてその荷重センサによる荷重情報の記憶態様を示すフローチャート。
【図６】同実施形態の荷重検出装置についてその荷重センサによるＥＣＵに対する送信情報の設定態様を示すフローチャート。
【図７】同実施形態の荷重検出装置についてそのＥＣＵによる故障判定態様を示すフローチャート。
【図８】（ａ）〜（ｅ）は、荷重検出装置の第２の実施形態について、それぞれ荷重検知電圧、バッファの記憶領域、故障検知ビット、再生波形データ及びＥＣＵの受信する荷重情報の時間的推移を示すタイムチャート。
【図９】同実施形態の荷重検出装置についてその荷重センサによる荷重情報の記憶態様を示すフローチャート。
【図１０】荷重検出装置の第３の実施形態について、そのＥＣＵによる故障判定態様を示すフローチャート。
【発明を実施するための形態】
【００１５】
以下、荷重検出装置の一実施形態について説明する。
図１に示すように、車両のフロアの上面には、シートの幅方向（図１において紙面に直交する方向）に並設されて前後方向に延在する対のロアレール１が固定されるとともに、両ロアレール１の各々には、アッパレール２が前後方向に移動可能に装着されている。
【００１６】
両アッパレール２の各々の上面には、前後一対のセンサ本体１０を介して所定の間隔をおいてロアアーム３が固定・支持されている。このロアアーム３は、シートＳＥの座面を構成するシートクッション４の骨格をなすものである。なお、各アッパレール２の前後で対をなすセンサ本体１０は、反対側の分も含めて合計４個が配設されている。
【００１７】
センサ本体１０は、第１ブラケット１１及び第２ブラケット１２と、起歪体１３と、荷重センサ１４とを備えている。そして、荷重センサ１４は、歪みゲージ１５及び信号処理装置２０を備えている。第１ブラケット１１は、アッパレール２の先端部においてその上面に固定されており、第２ブラケット１２は、ロアアーム３の先端部においてその下面に固定されている。起歪体１３は、板状に成形されており、その一側端部及び他側端部はそれぞれ第１ブラケット１１の上面及び第２ブラケット１２の下面に固着されている。そして、起歪体１３は、その中間部において撓み部１３ａを形成している。
【００１８】
荷重センサ１４の歪みゲージ１５はこの撓み部１３ａの上面に貼着されており、信号処理装置２０は第１ブラケット１１に支持される起歪体１３の一側端部の上面に搭載されている。起歪体１３は、第２ブラケット１２から上下方向の荷重が加わることで、第１ブラケット１１に支持される一側端部を支点に曲げ変形する。歪みゲージ１５は、この起歪体１３（撓み部１３ａ）の曲げ変形に伴う歪み量に応じて、ゲージ電圧を発生させるものである。このゲージ電圧は、基本的にシートＳＥに加わる荷重に応じてリニアに変動する。そして、信号処理装置２０は、このゲージ電圧に基づいて荷重情報及び故障情報を取得等する。
【００１９】
なお、ロアアーム３には、制御装置としてのＥＣＵ（Electronic Control Unit）３０が支持されており、このＥＣＵ３０には全て（４個）のセンサ本体１０に設けられた荷重センサ１４（信号処理装置２０）が信号線Ｗを介してディジタル双方向通信可能に接続されている。このＥＣＵ３０は、これら荷重センサ１４が取得した荷重情報を受信して、例えばシートＳＥが空席状態か着席状態かの乗員の有無を判定する。
【００２０】
次に、荷重センサ１４及びＥＣＵ３０の電気的構成について説明する。
図２に示すように、荷重センサ１４の信号処理装置２０は、アナログ信号処理部２１と、Ａ／Ｄ変換部２２と、比較器２３と、Ｄ／Ａ変換部２４と、ロジック回路を内蔵する第１の制御部としての制御部２５と、例えばＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）からなる書き換え可能な不揮発性のメモリ２６と、ＲＡＭからなる荷重情報記憶部としてのバッファ２７と、通信インタフェース２８とを備えている。そして、制御部２５は、通信インタフェース２８に接続された信号線Ｗを介してＥＣＵ３０と接続されている。この制御部２５は、ＥＣＵ３０との間での通信インタフェース２８を介した各種信号の送受、メモリ２６及びバッファ２７に対する各種情報（データ）の書き込み・読み出し等を行う。なお、制御部２５及びＥＣＵ３０（ＣＰＵ３１）間の送受信は、所定の通信周期Ｔｃ（例えば１００［ｍｓ］）ごとに繰り返される。
【００２１】
ここで、歪みゲージ１５は、シートＳＥに加わる荷重に応じたその歪み量に応じてゲージ電圧Ｖ１を発生し、これをアナログ信号処理部２１に出力する。アナログ信号処理部２１は、ゲージ電圧Ｖ１を増幅して荷重検知信号としての荷重検知電圧Ｖ２を生成し、これをＡ／Ｄ変換部２２及び比較器２３に出力する。
【００２２】
Ａ／Ｄ変換部２２は、前述の通信周期Ｔｃよりも十分に短い制御部２５の所定の演算周期Ｔａ（例えば１０［μｓ］）に合わせて荷重検知電圧Ｖ２をＡ／Ｄ変換して荷重情報信号を生成する。制御部２５は、この荷重情報信号を入力することで荷重情報としてメモリ２６に書き込み・記憶する。これにより、荷重センサ１４において演算周期Ｔａごとに荷重情報が取得される。つまり、メモリ２６には、制御部２５の演算周期Ｔａに合わせて最新の荷重情報が更新・記憶されている。
【００２３】
一方、比較器２３には、Ｄ／Ａ変換部２４からの閾値信号Ｓが併せて出力されている。詳述すると、メモリ２６には所定の故障検知閾値が予め記憶されており、制御部２５は、当該故障検知閾値を読み込んで故障検知閾値情報信号を生成し、これをＤ／Ａ変換部２４に出力する。Ｄ／Ａ変換部２４は、故障検知閾値情報信号をＤ／Ａ変換して閾値信号Ｓを生成し、これを比較器２３に出力する。
【００２４】
比較器２３は、荷重検知電圧Ｖ２と、閾値信号Ｓとを大小比較することでその比較結果に応じたレベル（ハイ又はロー）の信号を制御部２５に出力する。具体的には、比較器２３は、荷重検知電圧Ｖ２が閾値信号Ｓ以下のときにはローレベルとなり、荷重検知電圧Ｖ２が閾値信号Ｓよりも大きくなったときにはハイレベルとなる信号を出力する。これは、図４（ａ）に示すように、例えば車両衝突など修理を要する現象が発生しているとき、荷重検知電圧Ｖ２が過大となることが確認されていることによる。閾値信号Ｓの生成に係る故障検知閾値は、故障を検知する好適な値に設定されている。
【００２５】
制御部２５は、演算周期Ｔａごとに比較器２３の出力信号を監視するとともに、該出力信号のレベルに基づいて故障を検知し、これを故障情報としての故障検知ビットとしてメモリ２６に書き込み・記憶する。図４（ｃ）に示すように、この故障検知ビットは、荷重検知電圧Ｖ２が閾値信号Ｓ以下で比較器２３の出力信号がローレベルの状態を維持するときに「０」の状態を維持し、荷重検知電圧Ｖ２が閾値信号Ｓよりも大きくなって当該出力信号がハイレベルになったときにはそれ以降は「１」の状態を維持する。つまり、故障検知ビットは、故障が検知されることでその前後で論理が切り替わる。
【００２６】
また、図４（ｂ）に示すように、制御部２５は、故障検知ビットが「０」から「１」に切り替わると、それ以降の所定時間Ｔｄ（例えば２００［μｓ］）内で演算周期Ｔａごとに取得される荷重情報を故障検知時荷重情報として全てバッファ２７に記憶する。図４（ｂ）では、便宜的に演算周期Ｔａごとに故障検知時荷重情報が記憶されるバッファ２７の記憶領域を一列に並んだ四角形で表している。所定時間Ｔｄは、例えば車両衝突時の衝撃によって変動する荷重情報の推移を略包含できる時間に基づき設定されている。つまり、所定時間Ｔｄ内で演算周期Ｔａごとに取得された全ての故障検知時荷重情報同士を順番につなぐことで、故障が検知されたときの荷重情報（荷重検知電圧Ｖ２）の波形が概ね再生可能となっている。故障検知時荷重情報の個数Ｎが所定時間Ｔｄを演算周期Ｔａで除した値（＝Ｔｄ／Ｔａ、例えば２０）に一致することはいうまでもない。
【００２７】
さらに、制御部２５は、ＥＣＵ３０との間の各種信号の送受タイミングに合わせて（通信周期Ｔｃごとに）荷重情報及び故障検知ビットを通信インタフェース２８を通じてＥＣＵ３０に送信する。特に、制御部２５は、所定時間Ｔｄ内の故障検知時荷重情報の全てがバッファ２７に記憶された状態にあるとき、ＥＣＵ３０との間の各種信号の送受タイミングに合わせて当該故障検知時荷重情報を一つずつ順番に、通信インタフェース２８を通じてＥＣＵ３０に送信する。つまり、ＥＣＵ３０では、故障検知ビットが「０」から「１」に切り替わった後に制御部２５において演算周期Ｔａごとに取得された故障検知時荷重情報を、通信周期Ｔｃごとにゆっくりと受信することになる。なお、通信インタフェース２８は、ＥＣＵ３０との間で送受する各種信号を所定の通信用フォーマットに成形するためのものである。
【００２８】
図３に示すように、ＥＣＵ３０は、第２の制御部としてのＣＰＵ（Central Processing Unit）３１と、電源回路３２と、通信インタフェース３４とを備えている。そして、ＣＰＵ３１は、通信インタフェース３４に接続された信号線Ｗを介して全ての荷重センサ１４（制御部２４）と個別に接続されている。また、ＣＰＵ３１は、通信インタフェース３４を介して、エアバッグ装置のエアバッグＥＣＵ４１と接続されるとともに、例えばインストルメントパネルに設置されたインジケータ４２と接続されている。通信インタフェース３４は、荷重センサ１４等との間で送受する各種信号を所定の通信用フォーマットに成形するためのものである。なお、ＣＰＵ３１は、各種プログラム及びマップ等を記憶したＲＯＭ、各種データ等の読み書き可能なＲＡＭ等を内蔵している。
【００２９】
ＣＰＵ３１は、各荷重センサ１４との間の各種信号の送受タイミングに合わせて（通信周期Ｔｃごとに）、最新の荷重情報及び故障検知ビットを通信インタフェース３４を通じて受信する。そして、ＣＰＵ３１は、全ての荷重センサ１４から受信した荷重情報を合計してシート上荷重情報を算出し、これに基づいて前述の乗員の有無を判定する（乗員判定部）。
【００３０】
そして、ＣＰＵ３１は、通信インタフェース３４を介してエアバッグＥＣＵ４１に対し乗員の有無の判定結果を表す情報を出力する。エアバッグＥＣＵ４１は、取得した情報に基づきエアバッグの作動を好適に制御する。
【００３１】
また、ＣＰＵ３１は、いずれかの荷重センサ１４から受信した故障検知ビットが「１」のとき、当該荷重センサ１４のバッファ２７に記憶された一の故障検知時荷重情報を通信インタフェース３４を通じて受信して、当該故障検知時荷重情報を再生波形データＤｉ（ｉ＝１〜Ｎ）として記憶する（波形再生部）。具体的には、ＣＰＵ３１は、通信周期Ｔｃごとにバッファ２７に記憶された全ての故障検知時荷重情報（所定時間Ｔｄ内の故障検知時荷重情報）を古い順番に一つずつ通信インタフェース３４を通じて受信する。
【００３２】
図４（ｄ）に示すように、隣り合う再生波形データＤｉ（ｉ＝１〜Ｎ）同士の全てを順番につないだ波形は、通信周期Ｔｃが相対的に長い分だけ時間的に延びているものの、故障が検知されたときの荷重情報（荷重検知電圧Ｖ２）の波形（図４（ａ）参照）を概ね再生していることが確認される。
【００３３】
なお、図４（ｅ）には、通信周期ＴｃごとにＣＰＵ３１が通信インタフェース３４を通じて受信する最新の荷重情報を黒塗りの四角印で表している。また、通信周期ＴｃごとにＣＰＵ３１が通信インタフェース３４を通じて受信する故障検知ビットが「１」であること、即ち故障検知の状態であることを×印で表している。同図から明らかなように、ＣＰＵ３１は、故障検知ビットが「０」のときには最新の荷重情報を受信しており、故障検知ビットが「１」になることで最新の荷重情報の受信に加えて再生波形データＤｉを取得していることが確認される。
【００３４】
バッファ２７に記憶された全ての故障検知時荷重情報の受信が完了すると、ＣＰＵ３１は、それら全ての故障検知時荷重情報の再生波形データＤｉ（ｉ＝１〜Ｎ）に基づいて、例えば以下に示す＜１＞〜＜４＞の少なくとも一つの手順に基づいて故障検知条件を満たすか否かを判断する（故障判定部）。そして、ＣＰＵ３１は、その判断結果に応じて故障検知の処理を行い、あるいは故障検知キャンセルの処理を行う。具体的には、ＣＰＵ３１は、故障検知の処理において、インジケータ４２を点灯するべく通信インタフェース３４を介してインジケータ４２に駆動信号を出力し、故障検知キャンセルの処理においてインジケータ４２に対する駆動信号の出力を中止する。
【００３５】
＜１＞ＣＰＵ３１は、先頭の再生波形データＤｉ（ｉ＝１）が閾値信号Ｓ（故障検知閾値）相当の所定の上限閾値データＤｔｕよりも大きいか否かを判断（再判断）する。そして、ＣＰＵ３１は、再生波形データＤｉ（ｉ＝１）が上限閾値データＤｔｕよりも大きいと判断されれば故障検知の処理を行い、再生波形データＤｉ（ｉ＝１）が上限閾値データＤｔｕ以下と判断されれば故障検知キャンセルの処理を行う。
【００３６】
＜２＞ＣＰＵ３１は、その後の再生波形データＤｉ（ｉ＝ｌ＞１）が負数相当の所定の下限閾値データＤｔｄを下回るか否かを判断する。そして、ＣＰＵ３１は、再生波形データＤｉが下限閾値データＤｔｄを下回ると判断されれば故障検知の処理を行い、再生波形データＤｉが下限閾値データＤｔｄ以上と判断されれば故障検知キャンセルの処理を行う。これは、荷重検知電圧Ｖ２が過大となった後に著しく減少する際に、例えば車両衝突など修理を要する現象が発生している可能性が高いことによる。
【００３７】
＜３＞ＣＰＵ３１は、再生波形データＤｉ（ｉ＝ｌ＞１）が下限閾値データＤｔｄを下回ったとき、その際の番号ｌが所定番号Ｌを下回るか否か、即ち再生波形データＤｉが急減しているか否かを判断する。そして、ＣＰＵ３１は、番号ｌが所定番号Ｌを下回って再生波形データＤｉが急減していると判断されれば故障検知の処理を行い、番号ｌが所定番号Ｌ以上で再生波形データＤｉが急減していないと判断されれば故障検知キャンセルの処理を行う。これは、荷重検知電圧Ｖ２が過大となった後に急減する際に、例えば車両衝突など修理を要する現象が発生している可能性が高いことによる。
【００３８】
＜４＞ＣＰＵ３１は、更にその後の再生波形データＤｉ（ｉ＝ｍ＞ｌ）が正数に戻って一定範囲に収束したとき、その際の番号ｍが所定番号Ｍを下回るか否か、即ち再生波形データＤｉが急減してからの復帰・収束が迅速か否かを判断する。そして、ＣＰＵ３１は、番号ｍが所定番号Ｍを下回って再生波形データＤｉの急減からの復帰・収束が迅速であると判断されれば故障検知の処理を行い、番号ｍが所定番号Ｍ以上で再生波形データＤｉの急減からの復帰・収束が迅速でないと判断されれば故障検知キャンセルの処理を行う。これは、荷重検知電圧Ｖ２が急増減した後に速やかに復帰・収束した際、例えば車両衝突など修理を要する現象が発生している可能性が高いことによる。
【００３９】
つまり、ＣＰＵ３１は、その演算能力を活用して、＜１＞〜＜４＞の少なくとも一つの手順に基づきより高度な故障判定を行う。
次に、図５に示すフローチャートに基づいて、荷重センサ１４の制御部２５による故障検知時荷重情報の記憶態様について総括して説明する。この処理は、演算周期Ｔａごとに繰り返し実行されるものである。
【００４０】
処理がこのルーチンに移行すると、制御部２５は、ステップＳ１において、Ａ／Ｄ変換部２２におけるサンプリング時間が経過したか（荷重検知電圧Ｖ２のＡ／Ｄ変換が完了したか）否かに基づいて荷重更新条件が成立したか否かを判断する。そして、制御部２５は、荷重更新条件の成立を待って、ステップＳ２に移行し、前述の比較器２３の出力信号に基づいて、故障検知の有無を判断する。
【００４１】
ステップＳ２で故障検知があると判断されると、制御部２５は、ステップＳ３に移行して、バッファ２７にＮ個の故障検知時荷重情報（所定時間Ｔｄ内の全ての故障検知時荷重情報）が溜まったことを意味するサイズ上限の状態にあるか否かを判断する。そして、サイズ上限の状態でないと判断されると、制御部２５は、ステップＳ４に移行し、記憶領域の順番に従ってこのときの荷重情報を故障検知時荷重情報としてバッファ２７に記憶・更新する。そして、制御部２５はステップＳ５に移行する。一方、サイズ上限の状態であると判断されると、制御部２５は、バッファ２７を更新することなく（バッファ２７の更新を停止して）そのままステップＳ５に移行する。また、制御部２５は、ステップＳ２で故障検知がないと判断される場合も、そのままステップＳ５に移行する。つまり、ステップＳ２〜Ｓ４の処理により、故障検知があるときには、当初の記憶領域が空白になっているバッファ２７にＮ個の故障検知時荷重情報が溜まるまで演算周期Ｔａの都度、バッファ２７の更新が繰り返される。
【００４２】
ステップＳ５において、制御部２５は、このときの荷重情報に基づいて荷重演算を行う。これは、制御部２５により取得される荷重情報が実際の荷重に相関するものの、該荷重自体の数値を表していない場合にこれに一致するように演算・記憶させて情報の汎用性を向上させるためである。その後、制御部２５は、処理を一旦終了する。
【００４３】
次に、図６に示すフローチャートに基づいて、荷重センサ１４の制御部２５によるＥＣＵ３０に対する送信情報（応答データ）の設定態様について総括して説明する。この処理は、演算周期Ｔａごとに繰り返し実行されるものである。
【００４４】
処理がこのルーチンに移行すると、制御部２５は、ステップＳ１１において、ＥＣＵ３０からの要求があるか否かを判断する。この要求の有無は、例えば通信周期ＴｃごとにＥＣＵ３０から送信される要求信号の有無に基づいて判断される。そして、制御部２５は、ＥＣＵ３０からの要求がないと判断されればそのまま処理を一旦終了し、あると判断されればステップＳ１２に移行してＥＣＵ３０に送信すべき追加バッファデータがあるか否かを判断する。具体的には、バッファ２７にＮ個の故障検知時荷重情報（所定時間Ｔｄ内の全ての故障検知時荷重情報）が溜まったサイズ上限の状態にあって、ＥＣＵ３０に未送信の故障検知時荷重情報があるか否かを判断する。
【００４５】
ステップＳ１２で追加バッファデータがあると判断されると、制御部２５は、ステップＳ１３に移行して、追加バッファデータから応答データを設定する。具体的には、制御部２５は、ＥＣＵ３０に未送信の故障検知時荷重情報のうち、最も古い故障検知時荷重情報を読み込んで、これをＥＣＵ３０に対する送信情報として設定する。一方、ステップＳ１２で追加バッファデータがないと判断されると、制御部２５は、ステップＳ１４に移行して、追加バッファデータがないことを表す応答データ（例えば「０」）を設定する。
【００４６】
ステップＳ１３又はステップＳ１４で追加バッファデータの有無に応じて応答データを設定した制御部２５は、ステップＳ１５に移行して、他応答データを設定する。具体的には、制御部２５は、メモリ２６から最新の荷重情報及び故障検知ビットを読み込んで、これをＥＣＵ３０に対する送信情報として設定する。その後、制御部２５は、処理を一旦終了する。なお、ステップＳ１３又はステップＳ１４で設定された応答データは、ステップＳ１５で設定された他応答データと共にＥＣＵ３０に送信されるように構成されている。従って、例えばステップＳ１３で追加バッファデータから応答データが設定される場合には、最新の荷重情報及び故障検知ビットと共にバッファ２７の最も古い未送信の故障検知時荷重情報がＥＣＵ３０に送信される。
【００４７】
次に、図７に示すフローチャートに基づいて、ＥＣＵ３０のＣＰＵ３１による故障判定態様について総括して説明する。この処理は、荷重センサ１４（制御部２５）に対する前述の要求に合わせて通信周期Ｔｃごとに繰り返し実行されるものである。
【００４８】
処理がこのルーチンに移行すると、ＣＰＵ３１は、ステップＳ２１において、荷重更新が完了したか否かを判断する。具体的には、ＣＰＵ３１は、要求に伴って制御部２５から送信された最新の荷重情報等（応答データ）の到達が完了しているか否かを判断する。そして、ＣＰＵ３１は、荷重更新の完了を待って、ステップＳ２２に移行し、故障検知ビットの論理（「０」又は「１」）に基づいて、故障検知の有無を判断する。
【００４９】
ステップＳ２２で故障検知があると判断されると、ＣＰＵ３１は、ステップＳ２３に移行して故障ダイアグカウントＣＮＴをアップ（インクリメント）するとともに、ステップＳ２４に移行してこのときにバッファ２７から読み込み・送信された故障検知時荷重情報を再生波形データＤｉとして設定する。一方、ステップＳ２２で故障検知がないと判断されると、ＣＰＵ３１は、ステップＳ２５に移行して故障ダイアグカウントＣＮＴをクリアする（「０」にする）とともに、ステップＳ２６に移行して現在までに設定された再生波形データＤｉの全てを破棄（リセット）する。なお、故障ダイアグカウントＣＮＴは、故障検知ビットが連続して「１」となる通信回数、即ち故障検知ビットが「１」の状態を継続している時間を表すものである。
【００５０】
ステップＳ２４又はステップＳ２６の処理を行ったＣＰＵ３１は、ステップＳ２７に移行して故障ダイアグカウントＣＮＴが所定の閾値以上か否か、即ち故障検知ビットが「１」の状態を一定時間継続しているか否かを判断する。そして、故障ダイアグカウントＣＮＴが所定の閾値以上と判断されると、ＣＰＵ３１は、再生波形データを取得済みか否か、即ち全ての再生波形データＤｉ（ｉ＝１〜Ｎ）の設定が完了したか否かを判断する。なお、ステップＳ２７における判断は、閾値が値「Ｎ」であればステップＳ２８における判断と実質的に同等である。換言すれば、ステップＳ２７における判断によって、閾値が値「Ｎ」以外に設定されるときに、ステップＳ２８における判断とは別に故障検知ビットが「１」の状態を継続している時間を監視できる。
【００５１】
ステップＳ２８で再生波形データを取得済みと判断されると、ＣＰＵ３１は、ステップＳ２９に移行して、前述の＜１＞〜＜４＞の少なくとも一つの手順に基づいて、再生波形データＤｉ（ｉ＝１〜Ｎ）が故障検知条件を満たすか否かを判断する。そして、再生波形データＤｉ（ｉ＝１〜Ｎ）が故障検知条件を満たすと判断されると、ＣＰＵ３１は、ステップＳ３０に移行して故障検知・報知の処理を行い、処理を一旦終了する。具体的には、ＣＰＵ３１は、通信インタフェース３４を介してインジケータ４２に駆動信号を出力して該インジケータ４２を点灯駆動する。これにより、運転者等の乗員に対し、ディーラー等の整備工場に車両を持ち込むなどの対処を行うことが促される。
【００５２】
一方、ステップＳ２７において故障ダイアグカウントＣＮＴが所定の閾値未満と判断されると、ＣＰＵ３１は処理を一旦終了する。これは、何らかの事情で故障検知ビットが一時的に「１」の状態になった場合、故障でない可能性が高いためである。同様に、ステップＳ２８において再生波形データを取得済みでないと判断されると、ＣＰＵ３１は処理を一旦終了する。
【００５３】
また、ステップＳ２９において再生波形データＤｉ（ｉ＝１〜Ｎ）が故障検知条件を満たさないと判断されると、ＣＰＵ３１はステップＳ３１に移行して、荷重センサ１４のメモリ２６に記憶されている故障検知ビットをクリアする（「０」にする）べく、該当の要求信号を設定する。この要求信号が、例えば次回の通信タイミングで通信インタフェース３４等を通じて荷重センサ１４（制御部２５）に送信されると、制御部２５は、メモリ２６に記憶されている故障検知ビットをクリアするとともに、バッファ２７に記憶されているＮ個の故障検知時荷重情報の全てをクリアするようになっている。
【００５４】
続いて、ＣＰＵ３１は、ステップＳ３２に移行して故障ダイアグカウントＣＮＴをクリアするとともに、ステップＳ３３に移行して全ての再生波形データＤｉ（ｉ＝１〜Ｎ）を破棄する。そして、ＣＰＵ３１は処理を一旦終了する。
【００５５】
以上の説明から明らかなように、故障検知ビットの論理に関わらず、ステップＳ２９で故障検知条件を満たさない限り、インジケータ４２が点灯することはない。
以上詳述したように、本実施形態によれば、以下の作用効果を奏することができる。
【００５６】
（１）本実施形態では、ＣＰＵ３１は、所定時間Ｔｄ内における演算周期Ｔａごとの故障検知時荷重情報を受信・再生するとともに、当該再生された故障検知時荷重情報（再生波形データＤｉ）に基づいて故障の有無を判定する。この場合、ＣＰＵ３１は、ステップＳ２９における故障の有無の判定において、制御部２５における前述の閾値判定に準じた閾値判定（＜１＞の手順）に加えて、＜２＞〜＜４＞の少なくとも一つの手順に基づいて、例えば故障検知時荷重情報が増加及び減少の一方から他方に切り替わるまでの経過時間やそれらの変動か収束するまでの経過時間といった故障検知時荷重情報の推移（＜３＞〜＜４＞の手順）を利用することができる。このため、故障の有無の判定精度をより向上させることができる。そして、故障有りと判定（ステップＳ２９でＹＥＳ）した際にＣＰＵ３１が行う修理を促す報知の信頼性をより向上させることができる。一方、ＣＰＵ３１は、バッファ２７に記憶された所定時間Ｔｄ内における演算周期Ｔａごとの故障検知時荷重情報を通信周期Ｔｃごとに順次、受信すればよいため、通信負荷を増加しなくてもよい。つまり、通信能力（演算能力）の小さい簡易且つ安価なＣＰＵ３１のまま、故障の有無の判定精度を向上させることができる。
【００５７】
（第２の実施形態）
以下、荷重検出装置の第２の実施形態について説明する。なお、第２の実施形態は、主として第１の実施形態の荷重センサ１４の制御部２５による故障検知時荷重情報の記憶態様を変更した構成であるため、同様の部分についてはその詳細な説明は省略する。なお、本実施形態では、図２に示すように、バッファ２７に代えてリングバッファ５１を採用している。リングバッファ５１は、制御部２５が取得した直近のＮ個分の荷重情報を常時記憶している。そして、制御部２５は、演算周期Ｔａごとに新たに取得した荷重情報をＮ個のうちの最古の荷重情報が記憶されてリングバッファ５１の記憶領域に書き込む（上書きする）とともに、新たに最古となる荷重情報が記憶されてリングバッファ５１の記憶領域を先頭の記憶領域に設定する。つまり、リングバッファ５１には、Ｎ個分の荷重情報が古い順番に管理された状態で記憶されている。
【００５８】
従って、図８（ａ）に示すように、荷重検知電圧Ｖ２が閾値信号Ｓよりも大きくなって比較器２３の出力信号がハイレベルとなった時点でも、リングバッファ５１には直近のＮ個分の荷重情報が記憶された状態にある。
【００５９】
なお、制御部２５は、演算周期Ｔａごとに比較器２３の出力信号を監視するとともに、該出力信号のレベルに基づいて故障を検知し、これを故障情報としての故障検知ビットとしてメモリ２６に書き込み・記憶することは第１の実施形態と同様である。図８（ｃ）に示すように、故障が検知されることでその前後で故障検知ビットの論理が切り替わることはいうまでもない。
【００６０】
また、図８（ｂ）に示すように、制御部２５は、故障検知ビットが「０」から「１」に切り替わると、新たな荷重情報の記憶・更新を許可するリングバッファ５１の最終の記憶領域を設定する。図８（ｂ）では、便宜的にリングバッファ５１の更新が停止される段階で荷重情報が記憶されるリングバッファ５１の記憶領域を一列に並んだ四角形で表しており、特に更新が停止される最終の記憶領域にはハッチングを付している。同図から明らかなように、リングバッファ５１の更新が停止された状態では、該リングバッファ５１には荷重検知電圧Ｖ２が閾値信号Ｓよりも大きくなるまで急増する推移を含むように荷重情報が故障検知時荷重情報として記憶されている。つまり、所定時間Ｔｄ内で演算周期Ｔａごとに取得された全ての故障検知時荷重情報同士を順番につなぐことで、故障が検知される以前の状態を含む荷重情報（荷重検知電圧Ｖ２）の波形が概ね再生可能となっている。
【００６１】
制御部２５は、ＥＣＵ３０との間の各種信号の送受タイミングに合わせて（通信周期Ｔｃごとに）荷重情報及び故障検知ビットを通信インタフェース２８を通じてＥＣＵ３０（ＣＰＵ３１）に送信することは第１の実施形態と同様である。特に、制御部２５は、リングバッファ５１の更新が停止された状態にあるとき、ＥＣＵ３０との間の各種信号の送受タイミングに合わせてリングバッファ５１の故障検知時荷重情報を一つずつ古い順番に、通信インタフェース２８を通じてＥＣＵ３０に送信する。つまり、ＥＣＵ３０では、リングバッファ５１の更新が停止されるタイミング（所定時間Ｔｄの終期）までに制御部２５において演算周期Ｔａごとに取得されたＮ個分の故障検知時荷重情報を、通信周期Ｔｃごとにゆっくりと受信することになる。
【００６２】
ＥＣＵ３０（ＣＰＵ３１）は、いずれかの荷重センサ１４から受信した故障検知ビットが「１」のとき、当該荷重センサ１４のリングバッファ５１に記憶された一の故障検知時荷重情報を通信インタフェース３４を通じて受信して、該故障検知時荷重情報を再生波形データＤｉ（ｉ＝１〜Ｎ）として記憶する（波形再生部）。
【００６３】
図８（ｄ）に示すように、隣り合う再生波形データＤｉ（ｉ＝１〜Ｎ）同士の全てを順番につないだ波形は、通信周期Ｔｃが相対的に長い分だけ時間的に延びているものの、故障が検知される以前の状態を含む荷重情報（荷重検知電圧Ｖ２）の波形（図８（ａ）参照）を概ね再生していることが確認される。
【００６４】
なお、図８（ｅ）には、通信周期ＴｃごとにＣＰＵ３１が通信インタフェース３４を通じて受信する最新の荷重情報を黒塗りの四角印で表している。また、通信周期ＴｃごとにＣＰＵ３１が通信インタフェース３４を通じて受信する故障検知ビットが「１」であること、即ち故障検知の状態であることを×印で表している。同図から明らかなように、ＣＰＵ３１は、故障検知ビットが「０」のときには最新の荷重情報を受信しており、故障検知ビットが「１」になることで最新の荷重情報の受信に加えて再生波形データＤｉを取得していることが確認される。
【００６５】
次に、図９に示すフローチャートに基づいて、荷重センサ１４の制御部２５による故障検知時荷重情報の記憶態様について総括して説明する。この処理は、演算周期Ｔａごとに繰り返し実行されるものである。
【００６６】
処理がこのルーチンに移行すると、制御部２５は、前述のステップＳ１、Ｓ２の処理を行い、ステップＳ２で故障検知があると判断されると、ステップＳ４１に移行してリングバッファ５１の更新停止タイミング、即ち新たな荷重情報（故障検知時荷重情報）の記憶・更新を許可するリングバッファ５１の最終の記憶領域を設定する。この更新停止タイミングの設定は、故障検知ビットが「０」から「１」に切り替わるときに行われるもので、故障検知ビットが「１」の状態を継続する間は当初の設定が維持されるようになっている。
【００６７】
次に、制御部２５は、ステップＳ４２に移行して更新停止タイミングに到達したか否か、即ちステップＳ４１で設定されたリングバッファ５１の最終の記憶領域に新たな荷重情報が記憶・更新されたか否かを判断する。そして、更新停止タイミングに到達していないと判断されると、制御部２５は、ステップＳ４３に移行し、記憶領域の順番に従ってこのときの荷重情報をリングバッファ５１に記憶・更新する。そして、制御部２５は、前述のステップＳ５に移行して該当の処理を行い、処理を一旦終了する。また、ステップＳ４２において更新停止タイミングに到達していると判断されると、制御部２５は、そのままステップＳ５に移行して該当の処理を行い、処理を一旦終了する。
【００６８】
つまり、ステップＳ２，Ｓ４１〜Ｓ４３の処理により、故障検知があるときには、ステップＳ４１で設定されたリングバッファ５１の最終の記憶領域に新たな荷重情報が記憶・更新されるまで演算周期Ｔａの都度、リングバッファ５１の更新が繰り返される。これにより、リングバッファ５１にＮ個の故障検知時荷重情報が記憶される。
【００６９】
以上詳述したように、本実施形態によれば、前記第１の実施形態における効果に加えて以下に示す効果が得られるようになる。
（１）本実施形態では、リングバッファ５１に対する演算周期Ｔａごとの荷重情報の記憶・更新は、記憶済みの荷重情報の中で最も古い荷重情報を書き換えるとともに、この段階で最も古くなる荷重情報が記憶される記憶領域を先頭の記憶領域に設定すればよいため、制御部２５の処理負荷をより軽減することができる。
【００７０】
（２）本実施形態では、リングバッファ５１の更新停止タイミングの設定によって、ＣＰＵ３１は、故障検知ビットが「０」から「１」に切り替わる以前の故障検知時荷重情報を再生波形データＤｉとして取得することができる。
【００７１】
（第３の実施形態）
以下、荷重検出装置の第３の実施形態について説明する。なお、第３の実施形態は、前記第１又は第２の実施形態における故障判定に際して、衝突検知センサの検知信号を利用するように変更した構成であるため、同様の部分についてはその詳細な説明は省略する。
【００７２】
図３に示すように、ＥＣＵ３０のＣＰＵ３１には、車両衝突の有無を検知する衝突検知センサ４３が通信インタフェース３４を介して接続されており、衝突検知センサ４３の検知信号が入力されている。この衝突検知センサ４３は、例えば車両の前部に設置されるサテライトセンサーからなり、車両衝突の有無の状態を表す検知信号を出力する。そして、ＣＰＵ３１は、故障判定に際して衝突検知センサ４３の検知信号を利用する。
【００７３】
次に、図１０に示すフローチャートに基づいて、ＥＣＵ３０のＣＰＵ３１による故障判定態様について説明する。この処理は、図７のステップＳ２９までは同様であるため、それ以降の処理について説明する。同図に示すように、ステップＳ２９で再生波形データＤｉ（ｉ＝１〜Ｎ）が故障検知条件を満たすと判断されると（ステップＳ２９でＹＥＳ）、ＣＰＵ３１は、ステップＳ５１に移行し、衝突検知センサ４３の検知信号に基づいて、衝突検知の有無を判断する。
【００７４】
ここで、衝突検知がないと判断されると、ＣＰＵ３１は、ステップＳ３１に移行して前述の故障検知条件を満たさないと判断される場合（ステップＳ２９でＮＯ）と同様に処理する。つまり、ＣＰＵ３１は、衝突検知がないと判断される場合（ステップＳ５１でＮＯ）には、荷重センサ１４の故障がないと見なして故障有りの判定をキャンセルする（判定キャンセル部）。
【００７５】
一方、ステップＳ５１で衝突検知があると判断されると、ＣＰＵ３１は、ステップＳ３０に移行して前述の故障検知・報知の処理を行い、処理を一旦終了する。
以上詳述したように、本実施形態によれば、前記第１又は第２の実施形態の効果に加えて以下に示す効果が得られるようになる。
【００７６】
（１）本実施形態では、衝突検知センサ４３の検知信号が車両衝突無しの状態を表すのであれば、ＣＰＵ３１は、ステップＳ２９における故障有りの判定をキャンセルする。このため、ステップＳ３０における故障検知・報知の信頼性をいっそう向上させることができる。
【００７７】
なお、上記実施形態は以下のように変更してもよい。
・前記第３の実施形態において、衝突検知センサ４３はエアバッグＥＣＵ４１に接続されていてもよい。この場合、ＥＣＵ３０は、エアバッグＥＣＵ４１を通じて衝突検知センサ４３の検知信号（若しくは当該検知信号に基づいて所定の処理を施された衝突検知情報を含む信号）を受信すればよい。
【００７８】
・前記各実施形態において、所定時間Ｔｄの設定は一例であり、例えば複数倍の長さに延長してもよい。これは、現状の所定時間Ｔｄが、車両衝突時の衝撃によって変動する荷重情報の推移を略包含できる時間に設定されていることで、当該延長された所定時間（Ｔｄ）内で同様の荷重情報の推移の繰り返しが認められた場合、例えば乗員がシートＳＥを叩くなど人為的な原因によることを確認できるためである。
【００７９】
・前記各実施形態において、バッファ２７又はリングバッファ５１に記憶される故障検知時荷重情報の信号処理装置２０及びＥＣＵ３０間の送受信は、故障検知ビットが「１」のときに自動的に行うようにしてもよいし、「１」の故障検知ビットを受信したＥＣＵ３０からの要求信号に対して信号処理装置２０が応答するかたちで行うようにしてもよい。
【００８０】
・前記各実施形態において、バッファ２７又はリングバッファ５１に故障検知時荷重情報を記憶する所定時間Ｔｄは任意である。また、バッファ２７又はリングバッファ５１に記憶される故障検知時荷重情報の個数は任意である。さらに、バッファ２７又はリングバッファ５１に対する故障検知時荷重情報の更新周期は、演算周期Ｔａの整数倍であってもよい。つまり、バッファ２７又はリングバッファ５１に対する故障検知時荷重情報の更新を、演算周期Ｔａの１又は複数回おきに行うようにしてもよい。要は、ＣＰＵ３１が、再生された故障検知時荷重情報（再生波形データＤｉ）に基づいて故障の有無を好適に判定できるのであればよい。
【００８１】
・前記各実施形態において、再生波形データＤｉの物理量は、荷重値に相関する電圧値（荷重検知電圧Ｖ２相当）であってもよい。
・前記各実施形態において、制御部２５による故障情報の取得は、荷重検知電圧Ｖ２をＡ／Ｄ変換した荷重情報と故障検知閾値との大小関係に基づいて行ってもよい。
【００８２】
・前記各実施形態において、ＣＰＵ３１は、例えば荷重情報に基づいて乗員が大人なのか子供なのかを判定してもよい。
・前記各実施形態において、荷重センサ１４の個数は「４」に限定されるものではなく、自然数であればよい。
【００８３】
・前記各実施形態において、ＭＣＵ（マイコン）からなる制御部２５を採用してもよい。
・前記各実施形態において、センサ本体１０の構造は一例であって、シートＳＥに加わる荷重を検出し得るのであればその他の構造を採用してもよい。
【００８４】
・前記各実施形態において、故障検知時の報知（ステップＳ３０）は、例えばスピーカ又はブザーの発声で行ってもよい。
【符号の説明】
【００８５】
ＳＥ…シート、１４…荷重センサ、２５…制御部（第１の制御部）、２７…バッファ（荷重情報記憶部）、３０…ＥＣＵ（制御装置）、３１…ＣＰＵ（第２の制御部、波形再生部、故障判定部、判定キャンセル部）、４３…衝突検知センサ、５１…リングバッファ（荷重情報記憶部）。
【図１】
0006492963.tif 000002
【図２】
0006492963.tif 000003
【図３】
0006492963.tif 000004
【図４】
0006492963.tif 000005
【図５】
0006492963.tif 000006
【図６】
0006492963.tif 000007
【図７】
0006492963.tif 000008
【図８】
0006492963.tif 000009
【図９】
0006492963.tif 000010
【図１０】
0006492963.tif 000011