電子制御装置
【課題】車両と歩行者との衝突判定精度の向上を図ることが可能な電子制御装置を提供する。
【解決手段】第１周期で受信した加速度データを低加速度データと判別し、前記第１周期より短い第２周期で受信した加速度データを高加速度データと判別する電子制御装置であって、処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データと、前記高加速度データと判別可能な加速度データとが混在する場合、前記低加速度データと判別可能な加速度データを破棄するデータ処理部を備える。
【解決手段】第１周期で受信した加速度データを低加速度データと判別し、前記第１周期より短い第２周期で受信した加速度データを高加速度データと判別する電子制御装置であって、処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データと、前記高加速度データと判別可能な加速度データとが混在する場合、前記低加速度データと判別可能な加速度データを破棄するデータ処理部を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子制御装置に関する。
【背景技術】
【０００２】
走行中の車両が歩行者に衝突した場合、車両のフロントバンパと歩行者の下半身とが衝突するため、歩行者は車両のエンジンフード上に跳ね上げられて頭部を強打してしまい、深刻な傷害を負う恐れがある。近年では、歩行者との衝突が発生した場合に、エンジンフードの後端部を持ち上げることにより、エンジンフードとエンジンルーム内に配置された部品との間に空間を生じさせ、歩行者の頭部への衝撃を緩和する歩行者保護システム（いわゆるポップアップフードシステム）を搭載した車両も実用化されている。
【０００３】
図９は、従来における歩行者保護システムの構成概略図である。図９（ａ）は、歩行者保護システムが搭載された車両１００の側面図であり、図９（ｂ）は、この車両１００の上面図である。また、図９では、車両１００としてフロントエンジンタイプの車両を想定しており、エンジンルーム上にはエンジンフード１３０が開閉自在に設けられている。
【０００４】
この図９に示すように、歩行者保護システムは、車両１００におけるフロントバンパ１１０の車幅方向に沿って左側、中央、右側の各々に設置された３つの歩行者衝突センサ（ＰＣＳ：Pedestrian Crash Sensor）１０Ｌ、１０Ｃ、１０Ｒと、車両１００の前輪１２０に設置された車速センサ２０と、ＥＣＵ（Electronic Control Unit）３０と、エンジンフード１３０の後端部を持ち上げるためのパワーユニット８０とから構成されている。
【０００５】
フロントバンパ１１０の内部には、バンパビーム１４０と、歩行者脚部保護用のセーフティプレート１５０とが設けられており、ＰＣＳ１０Ｌ、１０Ｃ、１０Ｒは、セーフティプレート１５０の下部に設置されている。一般的にフロントバンパ１１０は樹脂製であるが、セーフティプレート１５０は衝突時に変形して衝突エネルギーを吸収しやすいような形状（例えば図９（ａ）に示すような「くの字」型）に成形された鉄板が用いられる。
【０００６】
図１０に示すように、各ＰＣＳ１０Ｌ、１０Ｃ、１０Ｒは、高感度（例えば±１００Ｇ）の衝突検出用の加速度センサ（ＨｉＧセンサ）１１と、低感度（例えば±１．５Ｇ）のフロントバンパ１１０の傾き角度検出用の加速度センサ（ＬｏＧセンサ）１２と、ＬｏＧセンサ１２の出力信号を８０ｍｓ周期でデジタル変換して加速度データ（ＬｏＧデータ）を生成すると共に、ＨｉＧセンサ１１の出力信号が閾値を越えた場合に、その出力信号を２５０μｓ周期でデジタル変換して加速度データ（ＨｉＧデータ）を生成するマイコン１３と、当該マイコン１３とＥＣＵ３０との間でシリアルデータの通信を行う通信ＩＣ１４とを備えている。
【０００７】
図１１は、ＨｉＧセンサ１１及びＬｏＧセンサ１２の出力信号と、通信ＩＣ１４からＥＣＵ３０へ送信されるシリアルデータ（換言すればＥＣＵ３０で受信されるシリアルデータ）の時間的関係を示すタイミングチャートである。この図１１に示すように、ＥＣＵ３０で受信されるシリアルデータには、８０ｍｓ周期で通信されるＬｏＧデータと、ＨｉＧセンサ１１の出力信号が閾値を越えた場合に、２５０μｓ周期で連続通信されるＨｉＧデータとが含まれている。なお、上記シリアルデータにおいて、ＬｏＧデータやＨｉＧデータが通信されない期間では、ノーコードデータ（無効データ）が通信される（この他、あるタイミングでエラーコードデータが通信される場合もある）。
【０００８】
このようにＰＣＳ１０Ｌ、１０Ｃ、１０ＲからＥＣＵ３０へ送信されるシリアルデータには、ＬｏＧデータとＨｉＧデータとの２種類のＧデータが含まれるが、両者を区別するためのユニークコード等の識別情報は含まれていない。そこで、ＥＣＵ３０は、ＬｏＧデータとＨｉＧデータとの受信周期の違いを利用して２種類のＧデータを判別する。つまり、ＥＣＵ３０は、８０ｍｓ周期で受信したＧデータをＬｏＧデータと判別し、２５０μｓ周期で受信したＧデータをＨｉＧデータと判別する。
【０００９】
そして、ＥＣＵ３０は、ＬｏＧデータに基づいてフロントバンパ１１０の傾き角度を監視する一方、ＨｉＧデータと車速センサ２０から送信される車速データに基づいてパワーユニット８０を制御することで、エンジンフード１３０のポップアップ動作を制御する。具体的には、ＥＣＵ３０は、車速が一定速度（例えば２５ｋｍ／ｈ）以上であって、ＨｉＧデータが衝突判定閾値を越えた場合に歩行者との衝突が発生したと判定し、パワーユニット８０を作動させてエンジンフード１３０をポップアップさせる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００６−２４８２７０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記のように、従来のＥＣＵ３０は、８０ｍｓ周期で受信したＧデータをＬｏＧデータと判別し、２５０μｓ周期で受信したＧデータをＨｉＧデータと判別していた。しかしながら、図１２に示すように、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後にＨｉＧデータの連続通信が開始された場合、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後に連続的に受信したＧデータの内、最初に受信したＧデータは８０ｍｓ周期で受信されたためＬｏＧデータと判別可能であるが、後続のＧデータが２５０μｓ周期で受信されたため、結局、最初に受信したＧデータの判別は不可能となる。
【００１２】
図１２に示すように、従来のＥＣＵ３０は、受信したシリアルデータをＨｉＧデータの受信周期と同じ２５０μｓ周期でサンプリングし、処理単位時間である１ｍｓ毎に４個のサンプリングデータを１組のデータセットとしてグループ化し、１つのデータセット内において、上記の理由でＬｏＧデータと判別可能なＧデータ（最初のＧデータ）と、ＨｉＧデータと判別可能なＧデータ（後続のＧデータ）とが混在する場合（パターンＡ〜Ｄのケースが考えられる）、最初のＧデータの判別が不可能となるため、そのデータセットを無効データとして破棄していた。
【００１３】
つまり、従来のＥＣＵ３０は、データセット内に存在する４個のサンプリングデータの全てがＨｉＧデータと判別可能なＧデータである場合のみ、そのデータセットを衝突判定用の有効データとして使用していた。この場合、図１２のパターンＡ〜Ｃに示すように、１つのデータセット内に有効なＨｉＧデータが存在するにも関わらず、そのデータセットを破棄してしまうことになり、衝突判定精度の低下を招く虞があった。
【００１４】
本発明は、上述した事情に鑑みてなされたものであり、車両と歩行者との衝突判定精度の向上を図ることが可能な電子制御装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明に係る電子制御装置は、第１周期で受信した加速度データを低加速度データと判別し、前記第１周期より短い第２周期で受信した加速度データを高加速度データと判別する電子制御装置であって、処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データと、前記高加速度データと判別可能な加速度データとが混在する場合、前記低加速度データと判別可能な加速度データを破棄するデータ処理部を備えることを特徴とする。
【００１６】
また、本発明に係る電子制御装置において、前記データ処理部は、前記処理単位時間内に取得した受信データから前記低加速度データと判別可能な加速度データを破棄した後、残った加速度データを前記高加速度データとして用いることを特徴とする。
【００１７】
また、本発明に係る電子制御装置において、前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記低加速度データとして用いることを特徴とする。
【００１８】
また、本発明に係る電子制御装置において、前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記高加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記高加速度データとして用いることを特徴とする。
【発明の効果】
【００１９】
本発明に係る電子制御装置によれば、処理単位時間内に取得した受信データ中に、低加速度データと判別可能な加速度データと、高加速度データと判別可能な加速度データとが混在する場合、低加速度データと判別可能な加速度データを破棄するため、従来のように、処理単位時間内に取得した受信データ中に存在する有効な高加速度データを破棄することなく、衝突判定に用いることができる。すなわち、本発明に係る電子制御装置によれば、車両と歩行者との衝突判定精度の向上を図ることが可能となる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施形態に係る電子制御装置（ＥＣＵ３０）のブロック構成図である。
【図２】本実施形態におけるＧデータの判別原理に関する第１説明図である。
【図３】本実施形態におけるＧデータの判別原理に関する第２説明図である。
【図４】ＥＣＵ３０のＣＰＵ４７が実行するサンプリングデータ判別処理を表すフローチャートである。
【図５】ＥＣＵ３０のＣＰＵ４７が実行するＧデータ判別処理を表すフローチャートである。
【図６】ＥＣＵ３０のＣＰＵ４７が実行するＧデータ判別処理を表すフローチャートである。
【図７】Ｇデータ判別処理におけるステップＳ４７の詳細処理を表すフローチャートである。
【図８】サンプリングデータ判別処理及びＧデータ判別処理の理解を容易にするためのタイミングチャートである。
【図９】従来における歩行者保護システムの構成概略図である。
【図１０】歩行者保護システムで使用される歩行者衝突センサ（ＰＣＳ）の内部構成図である。
【図１１】ＰＣＳから送信されるシリアルデータに含まれるＬｏＧデータ及びＨｉＧデータに関する説明図である。
【図１２】従来の問題点に関する説明図である。
【発明を実施するための形態】
【００２１】
以下、本発明の一実施形態について、図面を参照しながら説明する。なお、以下では、本発明に係る電子制御装置として、図９に示した歩行者保護システムで用いられるＥＣＵを例示して説明する。ただし、図９のＥＣＵ３０と区別するために、本実施形態におけるＥＣＵの符号を４０とする。
【００２２】
図１は、本実施形態におけるＥＣＵ４０のブロック構成図である。この図１に示すように、ＥＣＵ４０は、通信インタフェース４１、タイマ４２、ＲＯＭ(Read Only Memory)４３、ＲＡＭ(Random Access Memory)４４、パワーユニット駆動回路４６、及びＣＰＵ(Central Processing Unit)４７を備えている。なお、図１では、図９に示したＰＣＳ１０Ｌ、１０Ｃ、１０ＲをＰＣＳ１０と総称している。
【００２３】
通信インタフェース４１は、ＰＣＳ１０とのシリアル通信を実現可能とするインタフェースである。具体的には、この通信インタフェース４１は、ＰＣＳ１０から受信したシリアルデータを、ＣＰＵ４７から２５０μｓ周期で入力されるサンプリング要求に応じてサンプリングし、そのサンプリングデータをＣＰＵ４７に出力する。なお、図１１で説明したように、ＰＣＳ１０から送信されるシリアルデータには、８０ｍｓ周期（第１周期）で通信されるＬｏＧデータ（低加速度データ）と、ＨｉＧセンサ１１の出力信号が閾値を越えた場合に、２５０μｓ周期（第２周期）で連続通信されるＨｉＧデータ（高加速度データ）とが含まれている（ノーコードデータやエラーコードデータも含まれる）。
【００２４】
タイマ４２は、ＣＰＵ４７による制御に応じて計時動作を行うものであり、具体的には１００ｍｓにセットされた受信周期カウンタのカウントダウンを行う。ＲＯＭ４３は、ＣＰＵ４７によって実行される制御プログラムや各種設定データを予め記憶している不揮発性メモリである。ＲＡＭ４４は、ＣＰＵ４７が制御プログラムを実行して各種動作を行う際に、データの一時保存先に用いられる揮発性のワーキングメモリである。パワーユニット駆動回路４６は、ＣＰＵ４７から入力されるパワーユニット作動指令信号に応じて、パワーユニット８０を作動させるための駆動信号を生成し、当該駆動信号をパワーユニット８０に出力する。
【００２５】
ＣＰＵ４７（データ処理部）は、ＲＯＭ４３に記憶されている制御プログラムに従って歩行者保護システムを統括制御するものである。具体的には、このＣＰＵ４７は、通信インタフェース４１から取得したサンプリングデータ（ＬｏＧデータやＨｉＧデータ等）、及び車速センサ２０から取得した車速データに基づいて、フロントバンパ１１０の傾き角度の監視、及び歩行者との衝突判定を行い、衝突が発生したと判定した場合にパワーユニット作動指令信号をパワーユニット駆動回路４６に出力することで、パワーユニット８０を作動させる。なお、フロントバンパ１１０の傾き角度の監視にはＬｏＧデータが用いられ、歩行者との衝突判定にはＨｉＧデータ及び車速データが用いられる。
【００２６】
詳細は後述するが、このＣＰＵ４７は、通信インタフェース４１から２５０μｓ周期で取得したサンプリングデータを、処理単位時間である１ｍｓ毎にグループ化することで、４個のサンプリングデータを１組のデータセットとし、処理単位時間毎に得られるデータセット内に含まれるサンプリングデータが、加速度データ（以下、Ｇデータと称す）なのか、ノーコードデータなのか、或いはエラーコードデータなのかを判別するためのサンプリングデータ判別処理を行う。
【００２７】
さらに、このＣＰＵ４７は、処理単位時間毎に実行される（つまり１ｍｓ周期で実行される）上記サンプリングデータ判別処理の結果と、タイマ４２の計時結果（つまり受信周期カウンタの残り時間）とに基づき、現在のデータセットに存在するＧデータがＬｏＧデータなのか、或いはＨｉＧデータなのかを判別するためのＧデータ判別処理を行う。つまり、このＧデータ判別処理も処理単位時間毎に実行される（つまり１ｍｓ周期で実行される）処理である。
【００２８】
次に、上記のように構成された本実施形態におけるＥＣＵ４０の動作、特にＣＰＵ４７が実行するサンプリングデータ判別処理及びＧデータ判別処理について詳細に説明する。
まず、サンプリングデータ判別処理及びＧデータ判別処理の詳細説明に入る前に、その前提として、本実施形態におけるＧデータの判別原理について説明する。
【００２９】
図２は、ＨｉＧセンサ１１及びＬｏＧセンサ１２の出力信号と、ＥＣＵ４０で受信されるシリアルデータの時間的関係を示すタイミングチャートである。ここで、図２に示すように、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後にＨｉＧデータの連続通信が開始された場合を想定する。つまり、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後に連続的に受信したＧデータの内、最初に受信したＧデータは８０ｍｓ周期で受信されたためＬｏＧデータと判別可能であるが、後続のＧデータが２５０μｓ周期で受信されたため、結局、最初に受信したＧデータの判別は不可能となる。
【００３０】
本実施形態におけるＣＰＵ４７は、１つのデータセット内に（つまり処理単位時間内に取得した受信データ中に）、上記の理由でＬｏＧデータと判別可能なＧデータ（最初のＧデータ）と、ＨｉＧデータと判別可能なＧデータ（後続のＧデータ）とが混在する場合、ＬｏＧデータと判別可能なＧデータ、つまり最初のＧデータのみを破棄する。この時、図２中のパターンＡ〜Ｄのケースが考えられるが、データセット内に存在する有効なＨｉＧデータを破棄することなく衝突判定に用いることができ、衝突判定精度の向上を図ることが可能となる。
【００３１】
図３は、前回のＬｏＧデータ受信タイミングから８０ｍｓ未満でＨｉＧデータの連続通信が開始された場合を想定したタイミングチャートである。この場合、最初のＧデータはＬｏＧデータと判別可能なＧデータに該当せず、後続のＧデータが２５０μｓ周期で受信されたことから、データセット内に存在するＧデータは全てＨｉＧデータと判別することができる。つまり、ＣＰＵ４７は、１つのデータセット内に、ＨｉＧデータと判別可能なＧデータのみが存在する場合、それらＧデータをＨｉＧデータとして衝突判定に用いる。
【００３２】
以上説明したＧデータの判別原理を実現可能とする処理が、サンプリングデータ判別処理及びＧデータ判別処理である。図４は、サンプリングデータ判別処理を表すフローチャートであり、図５及び図６は、Ｇデータ判別処理を表すフローチャートであり、図７は、Ｇデータ判別処理におけるステップＳ４７の詳細処理を表すフローチャートであり、また、図８は、サンプリングデータ判別処理及びＧデータ判別処理の理解を容易にするためのタイミングチャートである。
【００３３】
既に述べたように、サンプリングデータ判別処理及びＧデータ判別処理は、処理単位時間である１ｍｓ周期で実行されるものであるが、以下では、図８に示すように、前回の処理単位時間に取得されたデータセット内にＬｏＧデータが存在し、このデータセット内の最後のサンプリングデータの取得完了タイミングから、タイマ４２によって１００ｍｓにセットされた受信周期カウンタのカウントダウンが開始される場合を想定する。なお、タイマ４２は、１ｍｓ単位でカウントダウンを行うものとする。
【００３４】
さて、図４に示すサンプリングデータ判別処理において、ＣＰＵ４７は、まず、Ｇデータ受信回数を「０」に初期化し（ステップＳ１）、変数ｎを「１」に初期化する（ステップＳ２）。そして、ＣＰＵ４７は、変数ｎが「５」より小さいか否かを判定し（ステップＳ３）、「Ｙｅｓ」の場合、ｎ個目のサンプリングデータを取得する（ステップＳ４）。そして、ＣＰＵ４７は、ｎ個目のサンプリングデータがノーコードデータか否かを判定し（ステップＳ５）、「Ｙｅｓ」の場合、変数ｎをインクリメントして上記ステップＳ３の処理に戻る（ステップＳ６）。
【００３５】
一方、上記ステップＳ５において、「Ｎｏ」の場合、つまりｎ個目のサンプリングデータがノーコードデータではない場合、ＣＰＵ４７は、ｎ個目のサンプリングデータがＧデータか否かを判定する（ステップＳ７）。このステップＳ７において、「Ｙｅｓ」の場合、つまりｎ個目のサンプリングデータがＧデータである場合、ＣＰＵ４７は、Ｇデータ受信回数が「０」と等しいか否かを判定する（ステップＳ８）。
【００３６】
ＣＰＵ４７は、ステップＳ８において「Ｙｅｓ」であれば、破棄候補ＧデータＧsubとしてｎ個目のサンプリングデータ（Ｇデータ）を設定し（ステップＳ９）、一方、「Ｎｏ」であれば、ステップＳ１０の処理に移行する。ここで、破棄候補ＧデータＧsubとは、後述する図５のＧデータ判別処理において、ＬｏＧデータと判別可能なＧデータであり、且つ今回のデータセット内にＨｉＧデータと判別可能なＧデータが混在する場合に破棄されるＧデータである。
【００３７】
そして、ＣＰＵ４７は、Ｇデータ積算値Ｇsumにｎ個目のサンプリングデータ（Ｇデータ）を加算し（ステップＳ１０）、さらに、Ｇデータ受信回数をインクリメントしてステップＳ６に移行する（ステップＳ１１）。一方、上記ステップＳ７において、「Ｎｏ」の場合、つまりｎ個目のサンプリングデータがＧデータではない場合、ＣＰＵ４７は、ｎ個目のサンプリングデータがエラーコードデータであると判断し、エラーデータとしてｎ個目のサンプリングデータを設定してステップＳ６の処理に移行する（ステップＳ１２）。
【００３８】
上記ステップＳ３〜Ｓ１２の処理は、上記ステップＳ３において「Ｎｏ」と判定されるまで繰り返される（つまり４回繰り返される）。これにより、今回のデータセット中に含まれる４個のサンプリングデータの判別が行われることになる。
【００３９】
一方、上記ステップＳ３において、「Ｎｏ」の場合、つまり変数ｎが５になった場合、ＣＰＵ４７は、Ｇデータ受信回数が「１」以上か否かを判定する（ステップＳ１３）。このステップＳ１３において、「Ｙｅｓ」の場合、ＣＰＵ４７は、Ｇデータ判別処理で使用する変数ＧaveとしてＧデータ積算値Ｇsumを設定した後、サンプリングデータ判別処理を終了する（ステップＳ１４）。一方、上記ステップＳ１３において、「Ｎｏ」の場合、ＣＰＵ４７は、エラーデータが「０」か否かを判定し（ステップＳ１５）、「Ｙｅｓ」であれば、変数ＧaveとしてＧデータ積算値Ｇsumを設定した後、サンプリングデータ判別処理を終了し（ステップＳ１６）、「Ｎｏ」であれば、そのままサンプリングデータ判別処理を終了する。
【００４０】
以上のようなサンプリングデータ判別処理が１ｍｓ周期で繰り返されることにより、各データセット毎に、サンプリングデータの判別結果、Ｇデータ受信回数、破棄候補ＧデータＧsub、変数Ｇave、及びエラーデータの各情報が得られることになる。
【００４１】
続いて、図５に示すＧデータ判別処理において、ＣＰＵ４７は、まず、Ｇデータ受信回数が「１」以上か否かを判定し（ステップＳ２１）、「Ｙｅｓ」の場合、受信周期カウンタの残り時間が９９ｍｓか否かを判定する（ステップＳ２２）。このステップＳ２２において、「Ｙｅｓ」の場合、つまり受信周期カウンタのカウントダウンが開始されてから１ｍｓが経過した場合（図８中のＴＡ期間に該当する場合）であって、今回のデータセット内に存在する全ＧデータがＨｉＧデータと判別可能である場合、ＣＰＵ４７は、ＨｉＧ受信フラグをオンにセットしてステップＳ３３の処理に移行する（ステップＳ２３）。
【００４２】
一方、上記ステップＳ２２において、「Ｎｏ」の場合、ＣＰＵ４７は、受信周期カウンタの残り時間が１５ｍｓ以上か否かを判定し（ステップＳ２４）、「Ｙｅｓ」であれば、受信周期カウンタの残り時間が２５ｍｓ以下か否かを判定する（ステップＳ２５）。このステップＳ２５において、「Ｎｏ」の場合、つまりカウントダウンが開始されてからの経過時間が１ｍｓより大きく、且つ７５ｍｓ未満の場合（図８中のＴＢ期間に該当する場合）であって、今回のデータセット内に存在する全ＧデータがＨｉＧデータと判別可能である場合、ＣＰＵ４７は、ＨｉＧ受信フラグがオフか否かを判定する（ステップＳ２６）。
【００４３】
このステップＳ２６において、「Ｙｅｓ」の場合、つまりＨｉＧ受信フラグがオフの場合、ＣＰＵ４７は、ＨｉＧ受信フラグをオンにし（ステップＳ２７）、さらに、Ｇデータ受信回数を「４」にセットしてステップＳ３３の処理に移行する（ステップＳ２８）。一方、上記ステップＳ２６において、「Ｎｏ」の場合、つまりＨｉＧ受信フラグがオンの場合、ＣＰＵ４７は、ステップＳ３３の処理に移行する。
【００４４】
また、上記ステップＳ２５において、「Ｙｅｓ」の場合、つまりカウントダウンが開始されてからの経過時間が７５ｍｓ以上８５ｍｓ以下の場合（図８中のＴＣ期間に該当する場合）であって、今回のデータセット内において最初に受信されたＧデータ（破棄候補ＧデータＧsub）がＬｏＧデータと判別可能である場合、ＣＰＵ４７は、Ｇデータ受信回数が「１」と等しいか否かを判定する（ステップＳ２９）。なお、ＬｏＧデータの受信周期は８０ｍｓであるが、マージンを考慮して７５ｍｓ以上８５ｍｓ以下の近似値に相当すれば、最初のＧデータをＬｏＧデータと判別可能とする。
【００４５】
上記ステップＳ２９において、「Ｙｅｓ」の場合、つまりＧデータ受信回数が「１」と等しい場合（換言すれば、破棄候補ＧデータＧsubをＬｏＧデータと判別可能であり、且つ今回のデータセット内のＧデータとして破棄候補ＧデータＧsubしか存在しない場合）、ＣＰＵ４７は、実際にフロントバンパ１１０の傾き角度の監視に使用するＬｏＧ変数として破棄候補ＧデータＧsubを設定し（ステップＳ３０）、さらに、ＨｉＧ受信フラグをオフにしてステップＳ３３の処理に移行する（ステップＳ３１）。
【００４６】
一方、上記ステップＳ２９において、「Ｎｏ」の場合、つまりＧデータ受信回数が「２」以上の場合（換言すれば、破棄候補ＧデータＧsubをＬｏＧデータと判別可能であり、且つ今回のデータセット内にＨｉＧデータと判別可能なＧデータが存在する場合）、ＣＰＵ４７は、変数Ｇaveから破棄候補ＧデータＧsubを減算し（つまりＬｏＧデータと判別可能なＧデータを破棄し）、減算後の値を新たな変数Ｇaveとした後、ステップＳ２７の処理に移行する（ステップＳ３２）。
【００４７】
また、上記ステップＳ２４において、「Ｎｏ」の場合、つまりカウントダウンが開始されてからの経過時間が８５ｍｓを越えた場合（図８中のＴＤ期間に該当する場合）、ＣＰＵ４７は、ステップＳ３３の処理に移行する。
上記のような、図８中のＴＡ期間、ＴＢ期間、ＴＣ期間、ＴＤ期間に該当するステップＳ２２〜Ｓ３２の実行後、ＣＰＵ４７は、エラーデータを「０」にリセットし（ステップＳ３３）、さらに、タイマ４２の受信周期カウンタをリセットしてステップＳ４６の処理に移行する（ステップＳ３４）。
【００４８】
一方、上記ステップＳ２１において、「Ｎｏ」の場合、つまりＧデータ受信回数が「０」だった場合、ＣＰＵ４７は、図６のステップＳ３５に移行し、受信周期カウンタの残り時間が「０」より大きいか否かを判定する（ステップＳ３５）。このステップＳ３５において、「Ｙｅｓ」の場合（図８中のＴＥ期間に該当する場合）、ＣＰＵ４７は、エラーデータを受信したか否か（エラーデータが「０」以外か否か）を判定する（ステップＳ３６）。ＣＰＵ４７は、上記ステップＳ３６において「Ｙｅｓ」であれば、ノーコードデータを受信したか否かを判定し（ステップＳ３７）、上記ステップＳ３６において「Ｎｏ」であれば、図５のステップＳ４６の処理に移行する。
【００４９】
そして、ＣＰＵ４７は、上記ステップＳ３７において「Ｎｏ」であれば、ＬｏＧ異常コードを受信したか否かを判定し（ステップＳ３８）、上記ステップＳ３７において「Ｙｅｓ」であれば、図５のステップＳ４６の処理に移行する。そして、ＣＰＵ４７は、上記ステップＳ３８において「Ｎｏ」であれば、ＰＣＳセンサ１０の故障診断に使用するＨｉＧ異常フラグをオンにセットし（ステップＳ３９）、上記ステップＳ３８において「Ｙｅｓ」であれば、ステップＳ４０の処理に移行する。そして、ＣＰＵ４７は、ＨｉＧ受信フラグをオフにセットし（ステップＳ４０）、さらに、タイマ４２の受信周期カウンタをリセットして図５のステップＳ４６の処理に移行する（ステップＳ４１）。
【００５０】
一方、上記ステップＳ３５において、「Ｎｏ」の場合、つまりカウントダウンが開始されてから１００ｍｓ以上経過してもＧデータを受信できなかった場合（図８中のＴＦ期間に該当する場合）、ＣＰＵ４７は、ＨｉＧ異常フラグをオンにセットし（ステップＳ４２）、ＨｉＧ受信フラグをオフにセットし（ステップＳ４３）、さらに、エラーデータを受信したか否か（エラーデータが「０」以外か否か）を判定する（ステップＳ４４）。ＣＰＵ４７は、上記ステップＳ４４において「Ｙｅｓ」であれば、エラーデータを記録して図５のステップＳ４６の処理に移行し（ステップＳ４５）、上記ステップＳ４４において「Ｎｏ」であれば、図５のステップＳ４６の処理に移行する。
【００５１】
図５に戻り、ステップＳ３４の実行後、或いは図６で説明したＴＥ期間、ＴＦ期間に該当するステップＳ３５〜Ｓ４５の実行後、ＣＰＵ４７は、ＨｉＧ受信フラグがオンか否かを判定し（ステップＳ４６）、「Ｙｅｓ」であれば、実際の衝突判定に用いるＨｉＧ変数にセットすべき衝突判定データＧの算出処理を行い（ステップＳ４７）、「Ｎｏ」であれば、ＨｉＧ変数に代替値として「０」をセットする（ステップＳ４８）。
【００５２】
図７は、上述したＧデータ判別処理のステップＳ４７における衝突判定データ算出処理の詳細を示すフローチャートである。この図７に示すように、まず、ＣＰＵ４７は、今回のデータセットの中からＨｉＧデータと判別可能なＧデータを取得し（ステップＳ５１）、Ｇデータ受信回数が「４」と等しいか否かを判定する（ステップＳ５２）。
【００５３】
このステップＳ５２において、「Ｙｅｓ」の場合、つまり今回のデータセットの中からＨｉＧデータと判別可能なＧデータを４個取得できた場合、ＣＰＵ４７は、ＨｉＧ代替要求フラグをオフにセットし（ステップＳ５３）、衝突判定データＧを算出した後、衝突判定データ算出処理を終了する（ステップＳ５４）。具体的には、ＨｉＧデータと判別可能な４個のＧデータを、それぞれＤ１、Ｄ２、Ｄ３、Ｄ４とすると、この時の衝突判定データＧは下記（１）式で表される。
Ｇ＝Ｄ１＋Ｄ２＋Ｄ３＋Ｄ４＝Ｇave ・・・・（１）
【００５４】
一方、上記ステップＳ５２において、「Ｎｏ」の場合、ＣＰＵ４７は、Ｇデータ受信回数が「３」と等しいか否かを判定する（ステップＳ５５）。このステップＳ５５において、「Ｙｅｓ」の場合、つまり今回のデータセットの中からＨｉＧデータと判別可能なＧデータを３個取得できた場合、ＣＰＵ４７は、ＨｉＧ代替要求フラグをオフにセットし（ステップＳ５６）、衝突判定データＧを算出した後、衝突判定データ算出処理を終了する（ステップＳ５７）。具体的には、ＨｉＧデータと判別可能な３個のＧデータを、それぞれＤ１、Ｄ２、Ｄ３とすると、この時の衝突判定データＧは下記（２）式で表される。
Ｇ＝４×｛（Ｄ１＋Ｄ２＋Ｄ３）／３｝
＝４×Ｇave／３ ・・・・（２）
【００５５】
一方、上記ステップＳ５５において、「Ｎｏ」の場合、つまりＧデータ受信回数が「２」、「１」、「０」のいずれかである場合、ＣＰＵ４７は、ＨｉＧ代替要求フラグがオンにセットされているか否かを判定する（ステップＳ５８）。このステップＳ５８において、「Ｙｅｓ」の場合、つまりＨｉＧ代替要求フラグがオンの場合、ＣＰＵ４７は、衝突判定データＧに代替値として「０」をセットした後、衝突判定データ算出処理を終了する（ステップＳ５９）。一方、上記ステップＳ５８において、「Ｎｏ」の場合、つまりＨｉＧ代替要求フラグがオフの場合、ＣＰＵ４７は、衝突判定データＧを前回値のまま保持し（ステップＳ６０）、ＨｉＧ代替要求フラグをオンにセットした後、衝突判定データ算出処理を終了する（ステップＳ６１）。
【００５６】
以上説明したように、本実施形態におけるＥＣＵ４０によれば、１つのデータセット内に（つまり処理単位時間内に取得した受信データ中に）、ＬｏＧデータと判別可能なＧデータ（最初のＧデータ）と、ＨｉＧデータと判別可能なＧデータ（後続のＧデータ）とが混在する場合、ＬｏＧデータと判別可能なＧデータ、つまり最初のＧデータのみを破棄するため、データセット内に存在する有効なＨｉＧデータを衝突判定に用いることができ、衝突判定精度の向上を図ることが可能となる。
【００５７】
なお、本発明は上記実施形態に限定されず、以下のような変形例が考えられる。
（１）上記実施形態では、ＰＣＳ１０から送信されるシリアルデータに、８０ｍｓ周期で通信されるＬｏＧデータと、２５０μｓ周期で連続通信されるＨｉＧデータとが含まれている場合を想定して説明したが、これらの周期はあくまで一例であり、本発明はこれ以外の周期でＬｏＧデータ及びＨｉＧデータが送信される場合にも適用することができる。
【００５８】
（２）上記実施形態では、１つのデータセット内に、ＬｏＧデータと判別可能なＧデータと、ＨｉＧデータと判別可能なＧデータとが混在する場合、ＬｏＧデータと判別可能なＧデータ、つまり最初のＧデータのみを破棄するという基本原理を実現させるために、図４〜図７に示すサンプリングデータ判別処理及びＧデータ判別処理を用いたが、これらの処理はあくまで基本原理を実現させるための一例に過ぎず、基本原理を実現可能であれば、他の処理を用いても良い。
【００５９】
（３）図９で示した歩行者保護システムは、あくまでＥＣＵ４０を適用可能なシステムの一例であり、車種、ＰＣＳ１０の種類、個数は図９のシステムに限定されず、様々なシステム構成に対して本発明に係る電子制御装置を適用可能であることは勿論である。
【符号の説明】
【００６０】
１００…車両、１１０…フロントバンパ、１３０…エンジンフード、１５０…セーフティプレート、１０Ｌ、１０Ｃ、１０Ｒ、１０…歩行者衝突センサ（ＰＣＳ）、２０…車速センサ、３０、４０…ＥＣＵ（Electronic Control Unit：電子制御装置）、４１…通信インタフェース、４２…タイマ、４３…ＲＯＭ(Read Only Memory)、４４…ＲＡＭ(Random Access Memory)、４６…パワーユニット駆動回路、４７…ＣＰＵ(Central Processing Unit：データ処理部)、８０…パワーユニット、１８０…エンジンフード
【技術分野】
【０００１】
本発明は、電子制御装置に関する。
【背景技術】
【０００２】
走行中の車両が歩行者に衝突した場合、車両のフロントバンパと歩行者の下半身とが衝突するため、歩行者は車両のエンジンフード上に跳ね上げられて頭部を強打してしまい、深刻な傷害を負う恐れがある。近年では、歩行者との衝突が発生した場合に、エンジンフードの後端部を持ち上げることにより、エンジンフードとエンジンルーム内に配置された部品との間に空間を生じさせ、歩行者の頭部への衝撃を緩和する歩行者保護システム（いわゆるポップアップフードシステム）を搭載した車両も実用化されている。
【０００３】
図９は、従来における歩行者保護システムの構成概略図である。図９（ａ）は、歩行者保護システムが搭載された車両１００の側面図であり、図９（ｂ）は、この車両１００の上面図である。また、図９では、車両１００としてフロントエンジンタイプの車両を想定しており、エンジンルーム上にはエンジンフード１３０が開閉自在に設けられている。
【０００４】
この図９に示すように、歩行者保護システムは、車両１００におけるフロントバンパ１１０の車幅方向に沿って左側、中央、右側の各々に設置された３つの歩行者衝突センサ（ＰＣＳ：Pedestrian Crash Sensor）１０Ｌ、１０Ｃ、１０Ｒと、車両１００の前輪１２０に設置された車速センサ２０と、ＥＣＵ（Electronic Control Unit）３０と、エンジンフード１３０の後端部を持ち上げるためのパワーユニット８０とから構成されている。
【０００５】
フロントバンパ１１０の内部には、バンパビーム１４０と、歩行者脚部保護用のセーフティプレート１５０とが設けられており、ＰＣＳ１０Ｌ、１０Ｃ、１０Ｒは、セーフティプレート１５０の下部に設置されている。一般的にフロントバンパ１１０は樹脂製であるが、セーフティプレート１５０は衝突時に変形して衝突エネルギーを吸収しやすいような形状（例えば図９（ａ）に示すような「くの字」型）に成形された鉄板が用いられる。
【０００６】
図１０に示すように、各ＰＣＳ１０Ｌ、１０Ｃ、１０Ｒは、高感度（例えば±１００Ｇ）の衝突検出用の加速度センサ（ＨｉＧセンサ）１１と、低感度（例えば±１．５Ｇ）のフロントバンパ１１０の傾き角度検出用の加速度センサ（ＬｏＧセンサ）１２と、ＬｏＧセンサ１２の出力信号を８０ｍｓ周期でデジタル変換して加速度データ（ＬｏＧデータ）を生成すると共に、ＨｉＧセンサ１１の出力信号が閾値を越えた場合に、その出力信号を２５０μｓ周期でデジタル変換して加速度データ（ＨｉＧデータ）を生成するマイコン１３と、当該マイコン１３とＥＣＵ３０との間でシリアルデータの通信を行う通信ＩＣ１４とを備えている。
【０００７】
図１１は、ＨｉＧセンサ１１及びＬｏＧセンサ１２の出力信号と、通信ＩＣ１４からＥＣＵ３０へ送信されるシリアルデータ（換言すればＥＣＵ３０で受信されるシリアルデータ）の時間的関係を示すタイミングチャートである。この図１１に示すように、ＥＣＵ３０で受信されるシリアルデータには、８０ｍｓ周期で通信されるＬｏＧデータと、ＨｉＧセンサ１１の出力信号が閾値を越えた場合に、２５０μｓ周期で連続通信されるＨｉＧデータとが含まれている。なお、上記シリアルデータにおいて、ＬｏＧデータやＨｉＧデータが通信されない期間では、ノーコードデータ（無効データ）が通信される（この他、あるタイミングでエラーコードデータが通信される場合もある）。
【０００８】
このようにＰＣＳ１０Ｌ、１０Ｃ、１０ＲからＥＣＵ３０へ送信されるシリアルデータには、ＬｏＧデータとＨｉＧデータとの２種類のＧデータが含まれるが、両者を区別するためのユニークコード等の識別情報は含まれていない。そこで、ＥＣＵ３０は、ＬｏＧデータとＨｉＧデータとの受信周期の違いを利用して２種類のＧデータを判別する。つまり、ＥＣＵ３０は、８０ｍｓ周期で受信したＧデータをＬｏＧデータと判別し、２５０μｓ周期で受信したＧデータをＨｉＧデータと判別する。
【０００９】
そして、ＥＣＵ３０は、ＬｏＧデータに基づいてフロントバンパ１１０の傾き角度を監視する一方、ＨｉＧデータと車速センサ２０から送信される車速データに基づいてパワーユニット８０を制御することで、エンジンフード１３０のポップアップ動作を制御する。具体的には、ＥＣＵ３０は、車速が一定速度（例えば２５ｋｍ／ｈ）以上であって、ＨｉＧデータが衝突判定閾値を越えた場合に歩行者との衝突が発生したと判定し、パワーユニット８０を作動させてエンジンフード１３０をポップアップさせる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００６−２４８２７０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記のように、従来のＥＣＵ３０は、８０ｍｓ周期で受信したＧデータをＬｏＧデータと判別し、２５０μｓ周期で受信したＧデータをＨｉＧデータと判別していた。しかしながら、図１２に示すように、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後にＨｉＧデータの連続通信が開始された場合、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後に連続的に受信したＧデータの内、最初に受信したＧデータは８０ｍｓ周期で受信されたためＬｏＧデータと判別可能であるが、後続のＧデータが２５０μｓ周期で受信されたため、結局、最初に受信したＧデータの判別は不可能となる。
【００１２】
図１２に示すように、従来のＥＣＵ３０は、受信したシリアルデータをＨｉＧデータの受信周期と同じ２５０μｓ周期でサンプリングし、処理単位時間である１ｍｓ毎に４個のサンプリングデータを１組のデータセットとしてグループ化し、１つのデータセット内において、上記の理由でＬｏＧデータと判別可能なＧデータ（最初のＧデータ）と、ＨｉＧデータと判別可能なＧデータ（後続のＧデータ）とが混在する場合（パターンＡ〜Ｄのケースが考えられる）、最初のＧデータの判別が不可能となるため、そのデータセットを無効データとして破棄していた。
【００１３】
つまり、従来のＥＣＵ３０は、データセット内に存在する４個のサンプリングデータの全てがＨｉＧデータと判別可能なＧデータである場合のみ、そのデータセットを衝突判定用の有効データとして使用していた。この場合、図１２のパターンＡ〜Ｃに示すように、１つのデータセット内に有効なＨｉＧデータが存在するにも関わらず、そのデータセットを破棄してしまうことになり、衝突判定精度の低下を招く虞があった。
【００１４】
本発明は、上述した事情に鑑みてなされたものであり、車両と歩行者との衝突判定精度の向上を図ることが可能な電子制御装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明に係る電子制御装置は、第１周期で受信した加速度データを低加速度データと判別し、前記第１周期より短い第２周期で受信した加速度データを高加速度データと判別する電子制御装置であって、処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データと、前記高加速度データと判別可能な加速度データとが混在する場合、前記低加速度データと判別可能な加速度データを破棄するデータ処理部を備えることを特徴とする。
【００１６】
また、本発明に係る電子制御装置において、前記データ処理部は、前記処理単位時間内に取得した受信データから前記低加速度データと判別可能な加速度データを破棄した後、残った加速度データを前記高加速度データとして用いることを特徴とする。
【００１７】
また、本発明に係る電子制御装置において、前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記低加速度データとして用いることを特徴とする。
【００１８】
また、本発明に係る電子制御装置において、前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記高加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記高加速度データとして用いることを特徴とする。
【発明の効果】
【００１９】
本発明に係る電子制御装置によれば、処理単位時間内に取得した受信データ中に、低加速度データと判別可能な加速度データと、高加速度データと判別可能な加速度データとが混在する場合、低加速度データと判別可能な加速度データを破棄するため、従来のように、処理単位時間内に取得した受信データ中に存在する有効な高加速度データを破棄することなく、衝突判定に用いることができる。すなわち、本発明に係る電子制御装置によれば、車両と歩行者との衝突判定精度の向上を図ることが可能となる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施形態に係る電子制御装置（ＥＣＵ３０）のブロック構成図である。
【図２】本実施形態におけるＧデータの判別原理に関する第１説明図である。
【図３】本実施形態におけるＧデータの判別原理に関する第２説明図である。
【図４】ＥＣＵ３０のＣＰＵ４７が実行するサンプリングデータ判別処理を表すフローチャートである。
【図５】ＥＣＵ３０のＣＰＵ４７が実行するＧデータ判別処理を表すフローチャートである。
【図６】ＥＣＵ３０のＣＰＵ４７が実行するＧデータ判別処理を表すフローチャートである。
【図７】Ｇデータ判別処理におけるステップＳ４７の詳細処理を表すフローチャートである。
【図８】サンプリングデータ判別処理及びＧデータ判別処理の理解を容易にするためのタイミングチャートである。
【図９】従来における歩行者保護システムの構成概略図である。
【図１０】歩行者保護システムで使用される歩行者衝突センサ（ＰＣＳ）の内部構成図である。
【図１１】ＰＣＳから送信されるシリアルデータに含まれるＬｏＧデータ及びＨｉＧデータに関する説明図である。
【図１２】従来の問題点に関する説明図である。
【発明を実施するための形態】
【００２１】
以下、本発明の一実施形態について、図面を参照しながら説明する。なお、以下では、本発明に係る電子制御装置として、図９に示した歩行者保護システムで用いられるＥＣＵを例示して説明する。ただし、図９のＥＣＵ３０と区別するために、本実施形態におけるＥＣＵの符号を４０とする。
【００２２】
図１は、本実施形態におけるＥＣＵ４０のブロック構成図である。この図１に示すように、ＥＣＵ４０は、通信インタフェース４１、タイマ４２、ＲＯＭ(Read Only Memory)４３、ＲＡＭ(Random Access Memory)４４、パワーユニット駆動回路４６、及びＣＰＵ(Central Processing Unit)４７を備えている。なお、図１では、図９に示したＰＣＳ１０Ｌ、１０Ｃ、１０ＲをＰＣＳ１０と総称している。
【００２３】
通信インタフェース４１は、ＰＣＳ１０とのシリアル通信を実現可能とするインタフェースである。具体的には、この通信インタフェース４１は、ＰＣＳ１０から受信したシリアルデータを、ＣＰＵ４７から２５０μｓ周期で入力されるサンプリング要求に応じてサンプリングし、そのサンプリングデータをＣＰＵ４７に出力する。なお、図１１で説明したように、ＰＣＳ１０から送信されるシリアルデータには、８０ｍｓ周期（第１周期）で通信されるＬｏＧデータ（低加速度データ）と、ＨｉＧセンサ１１の出力信号が閾値を越えた場合に、２５０μｓ周期（第２周期）で連続通信されるＨｉＧデータ（高加速度データ）とが含まれている（ノーコードデータやエラーコードデータも含まれる）。
【００２４】
タイマ４２は、ＣＰＵ４７による制御に応じて計時動作を行うものであり、具体的には１００ｍｓにセットされた受信周期カウンタのカウントダウンを行う。ＲＯＭ４３は、ＣＰＵ４７によって実行される制御プログラムや各種設定データを予め記憶している不揮発性メモリである。ＲＡＭ４４は、ＣＰＵ４７が制御プログラムを実行して各種動作を行う際に、データの一時保存先に用いられる揮発性のワーキングメモリである。パワーユニット駆動回路４６は、ＣＰＵ４７から入力されるパワーユニット作動指令信号に応じて、パワーユニット８０を作動させるための駆動信号を生成し、当該駆動信号をパワーユニット８０に出力する。
【００２５】
ＣＰＵ４７（データ処理部）は、ＲＯＭ４３に記憶されている制御プログラムに従って歩行者保護システムを統括制御するものである。具体的には、このＣＰＵ４７は、通信インタフェース４１から取得したサンプリングデータ（ＬｏＧデータやＨｉＧデータ等）、及び車速センサ２０から取得した車速データに基づいて、フロントバンパ１１０の傾き角度の監視、及び歩行者との衝突判定を行い、衝突が発生したと判定した場合にパワーユニット作動指令信号をパワーユニット駆動回路４６に出力することで、パワーユニット８０を作動させる。なお、フロントバンパ１１０の傾き角度の監視にはＬｏＧデータが用いられ、歩行者との衝突判定にはＨｉＧデータ及び車速データが用いられる。
【００２６】
詳細は後述するが、このＣＰＵ４７は、通信インタフェース４１から２５０μｓ周期で取得したサンプリングデータを、処理単位時間である１ｍｓ毎にグループ化することで、４個のサンプリングデータを１組のデータセットとし、処理単位時間毎に得られるデータセット内に含まれるサンプリングデータが、加速度データ（以下、Ｇデータと称す）なのか、ノーコードデータなのか、或いはエラーコードデータなのかを判別するためのサンプリングデータ判別処理を行う。
【００２７】
さらに、このＣＰＵ４７は、処理単位時間毎に実行される（つまり１ｍｓ周期で実行される）上記サンプリングデータ判別処理の結果と、タイマ４２の計時結果（つまり受信周期カウンタの残り時間）とに基づき、現在のデータセットに存在するＧデータがＬｏＧデータなのか、或いはＨｉＧデータなのかを判別するためのＧデータ判別処理を行う。つまり、このＧデータ判別処理も処理単位時間毎に実行される（つまり１ｍｓ周期で実行される）処理である。
【００２８】
次に、上記のように構成された本実施形態におけるＥＣＵ４０の動作、特にＣＰＵ４７が実行するサンプリングデータ判別処理及びＧデータ判別処理について詳細に説明する。
まず、サンプリングデータ判別処理及びＧデータ判別処理の詳細説明に入る前に、その前提として、本実施形態におけるＧデータの判別原理について説明する。
【００２９】
図２は、ＨｉＧセンサ１１及びＬｏＧセンサ１２の出力信号と、ＥＣＵ４０で受信されるシリアルデータの時間的関係を示すタイミングチャートである。ここで、図２に示すように、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後にＨｉＧデータの連続通信が開始された場合を想定する。つまり、前回のＬｏＧデータ受信タイミングから８０ｍｓ経過後に連続的に受信したＧデータの内、最初に受信したＧデータは８０ｍｓ周期で受信されたためＬｏＧデータと判別可能であるが、後続のＧデータが２５０μｓ周期で受信されたため、結局、最初に受信したＧデータの判別は不可能となる。
【００３０】
本実施形態におけるＣＰＵ４７は、１つのデータセット内に（つまり処理単位時間内に取得した受信データ中に）、上記の理由でＬｏＧデータと判別可能なＧデータ（最初のＧデータ）と、ＨｉＧデータと判別可能なＧデータ（後続のＧデータ）とが混在する場合、ＬｏＧデータと判別可能なＧデータ、つまり最初のＧデータのみを破棄する。この時、図２中のパターンＡ〜Ｄのケースが考えられるが、データセット内に存在する有効なＨｉＧデータを破棄することなく衝突判定に用いることができ、衝突判定精度の向上を図ることが可能となる。
【００３１】
図３は、前回のＬｏＧデータ受信タイミングから８０ｍｓ未満でＨｉＧデータの連続通信が開始された場合を想定したタイミングチャートである。この場合、最初のＧデータはＬｏＧデータと判別可能なＧデータに該当せず、後続のＧデータが２５０μｓ周期で受信されたことから、データセット内に存在するＧデータは全てＨｉＧデータと判別することができる。つまり、ＣＰＵ４７は、１つのデータセット内に、ＨｉＧデータと判別可能なＧデータのみが存在する場合、それらＧデータをＨｉＧデータとして衝突判定に用いる。
【００３２】
以上説明したＧデータの判別原理を実現可能とする処理が、サンプリングデータ判別処理及びＧデータ判別処理である。図４は、サンプリングデータ判別処理を表すフローチャートであり、図５及び図６は、Ｇデータ判別処理を表すフローチャートであり、図７は、Ｇデータ判別処理におけるステップＳ４７の詳細処理を表すフローチャートであり、また、図８は、サンプリングデータ判別処理及びＧデータ判別処理の理解を容易にするためのタイミングチャートである。
【００３３】
既に述べたように、サンプリングデータ判別処理及びＧデータ判別処理は、処理単位時間である１ｍｓ周期で実行されるものであるが、以下では、図８に示すように、前回の処理単位時間に取得されたデータセット内にＬｏＧデータが存在し、このデータセット内の最後のサンプリングデータの取得完了タイミングから、タイマ４２によって１００ｍｓにセットされた受信周期カウンタのカウントダウンが開始される場合を想定する。なお、タイマ４２は、１ｍｓ単位でカウントダウンを行うものとする。
【００３４】
さて、図４に示すサンプリングデータ判別処理において、ＣＰＵ４７は、まず、Ｇデータ受信回数を「０」に初期化し（ステップＳ１）、変数ｎを「１」に初期化する（ステップＳ２）。そして、ＣＰＵ４７は、変数ｎが「５」より小さいか否かを判定し（ステップＳ３）、「Ｙｅｓ」の場合、ｎ個目のサンプリングデータを取得する（ステップＳ４）。そして、ＣＰＵ４７は、ｎ個目のサンプリングデータがノーコードデータか否かを判定し（ステップＳ５）、「Ｙｅｓ」の場合、変数ｎをインクリメントして上記ステップＳ３の処理に戻る（ステップＳ６）。
【００３５】
一方、上記ステップＳ５において、「Ｎｏ」の場合、つまりｎ個目のサンプリングデータがノーコードデータではない場合、ＣＰＵ４７は、ｎ個目のサンプリングデータがＧデータか否かを判定する（ステップＳ７）。このステップＳ７において、「Ｙｅｓ」の場合、つまりｎ個目のサンプリングデータがＧデータである場合、ＣＰＵ４７は、Ｇデータ受信回数が「０」と等しいか否かを判定する（ステップＳ８）。
【００３６】
ＣＰＵ４７は、ステップＳ８において「Ｙｅｓ」であれば、破棄候補ＧデータＧsubとしてｎ個目のサンプリングデータ（Ｇデータ）を設定し（ステップＳ９）、一方、「Ｎｏ」であれば、ステップＳ１０の処理に移行する。ここで、破棄候補ＧデータＧsubとは、後述する図５のＧデータ判別処理において、ＬｏＧデータと判別可能なＧデータであり、且つ今回のデータセット内にＨｉＧデータと判別可能なＧデータが混在する場合に破棄されるＧデータである。
【００３７】
そして、ＣＰＵ４７は、Ｇデータ積算値Ｇsumにｎ個目のサンプリングデータ（Ｇデータ）を加算し（ステップＳ１０）、さらに、Ｇデータ受信回数をインクリメントしてステップＳ６に移行する（ステップＳ１１）。一方、上記ステップＳ７において、「Ｎｏ」の場合、つまりｎ個目のサンプリングデータがＧデータではない場合、ＣＰＵ４７は、ｎ個目のサンプリングデータがエラーコードデータであると判断し、エラーデータとしてｎ個目のサンプリングデータを設定してステップＳ６の処理に移行する（ステップＳ１２）。
【００３８】
上記ステップＳ３〜Ｓ１２の処理は、上記ステップＳ３において「Ｎｏ」と判定されるまで繰り返される（つまり４回繰り返される）。これにより、今回のデータセット中に含まれる４個のサンプリングデータの判別が行われることになる。
【００３９】
一方、上記ステップＳ３において、「Ｎｏ」の場合、つまり変数ｎが５になった場合、ＣＰＵ４７は、Ｇデータ受信回数が「１」以上か否かを判定する（ステップＳ１３）。このステップＳ１３において、「Ｙｅｓ」の場合、ＣＰＵ４７は、Ｇデータ判別処理で使用する変数ＧaveとしてＧデータ積算値Ｇsumを設定した後、サンプリングデータ判別処理を終了する（ステップＳ１４）。一方、上記ステップＳ１３において、「Ｎｏ」の場合、ＣＰＵ４７は、エラーデータが「０」か否かを判定し（ステップＳ１５）、「Ｙｅｓ」であれば、変数ＧaveとしてＧデータ積算値Ｇsumを設定した後、サンプリングデータ判別処理を終了し（ステップＳ１６）、「Ｎｏ」であれば、そのままサンプリングデータ判別処理を終了する。
【００４０】
以上のようなサンプリングデータ判別処理が１ｍｓ周期で繰り返されることにより、各データセット毎に、サンプリングデータの判別結果、Ｇデータ受信回数、破棄候補ＧデータＧsub、変数Ｇave、及びエラーデータの各情報が得られることになる。
【００４１】
続いて、図５に示すＧデータ判別処理において、ＣＰＵ４７は、まず、Ｇデータ受信回数が「１」以上か否かを判定し（ステップＳ２１）、「Ｙｅｓ」の場合、受信周期カウンタの残り時間が９９ｍｓか否かを判定する（ステップＳ２２）。このステップＳ２２において、「Ｙｅｓ」の場合、つまり受信周期カウンタのカウントダウンが開始されてから１ｍｓが経過した場合（図８中のＴＡ期間に該当する場合）であって、今回のデータセット内に存在する全ＧデータがＨｉＧデータと判別可能である場合、ＣＰＵ４７は、ＨｉＧ受信フラグをオンにセットしてステップＳ３３の処理に移行する（ステップＳ２３）。
【００４２】
一方、上記ステップＳ２２において、「Ｎｏ」の場合、ＣＰＵ４７は、受信周期カウンタの残り時間が１５ｍｓ以上か否かを判定し（ステップＳ２４）、「Ｙｅｓ」であれば、受信周期カウンタの残り時間が２５ｍｓ以下か否かを判定する（ステップＳ２５）。このステップＳ２５において、「Ｎｏ」の場合、つまりカウントダウンが開始されてからの経過時間が１ｍｓより大きく、且つ７５ｍｓ未満の場合（図８中のＴＢ期間に該当する場合）であって、今回のデータセット内に存在する全ＧデータがＨｉＧデータと判別可能である場合、ＣＰＵ４７は、ＨｉＧ受信フラグがオフか否かを判定する（ステップＳ２６）。
【００４３】
このステップＳ２６において、「Ｙｅｓ」の場合、つまりＨｉＧ受信フラグがオフの場合、ＣＰＵ４７は、ＨｉＧ受信フラグをオンにし（ステップＳ２７）、さらに、Ｇデータ受信回数を「４」にセットしてステップＳ３３の処理に移行する（ステップＳ２８）。一方、上記ステップＳ２６において、「Ｎｏ」の場合、つまりＨｉＧ受信フラグがオンの場合、ＣＰＵ４７は、ステップＳ３３の処理に移行する。
【００４４】
また、上記ステップＳ２５において、「Ｙｅｓ」の場合、つまりカウントダウンが開始されてからの経過時間が７５ｍｓ以上８５ｍｓ以下の場合（図８中のＴＣ期間に該当する場合）であって、今回のデータセット内において最初に受信されたＧデータ（破棄候補ＧデータＧsub）がＬｏＧデータと判別可能である場合、ＣＰＵ４７は、Ｇデータ受信回数が「１」と等しいか否かを判定する（ステップＳ２９）。なお、ＬｏＧデータの受信周期は８０ｍｓであるが、マージンを考慮して７５ｍｓ以上８５ｍｓ以下の近似値に相当すれば、最初のＧデータをＬｏＧデータと判別可能とする。
【００４５】
上記ステップＳ２９において、「Ｙｅｓ」の場合、つまりＧデータ受信回数が「１」と等しい場合（換言すれば、破棄候補ＧデータＧsubをＬｏＧデータと判別可能であり、且つ今回のデータセット内のＧデータとして破棄候補ＧデータＧsubしか存在しない場合）、ＣＰＵ４７は、実際にフロントバンパ１１０の傾き角度の監視に使用するＬｏＧ変数として破棄候補ＧデータＧsubを設定し（ステップＳ３０）、さらに、ＨｉＧ受信フラグをオフにしてステップＳ３３の処理に移行する（ステップＳ３１）。
【００４６】
一方、上記ステップＳ２９において、「Ｎｏ」の場合、つまりＧデータ受信回数が「２」以上の場合（換言すれば、破棄候補ＧデータＧsubをＬｏＧデータと判別可能であり、且つ今回のデータセット内にＨｉＧデータと判別可能なＧデータが存在する場合）、ＣＰＵ４７は、変数Ｇaveから破棄候補ＧデータＧsubを減算し（つまりＬｏＧデータと判別可能なＧデータを破棄し）、減算後の値を新たな変数Ｇaveとした後、ステップＳ２７の処理に移行する（ステップＳ３２）。
【００４７】
また、上記ステップＳ２４において、「Ｎｏ」の場合、つまりカウントダウンが開始されてからの経過時間が８５ｍｓを越えた場合（図８中のＴＤ期間に該当する場合）、ＣＰＵ４７は、ステップＳ３３の処理に移行する。
上記のような、図８中のＴＡ期間、ＴＢ期間、ＴＣ期間、ＴＤ期間に該当するステップＳ２２〜Ｓ３２の実行後、ＣＰＵ４７は、エラーデータを「０」にリセットし（ステップＳ３３）、さらに、タイマ４２の受信周期カウンタをリセットしてステップＳ４６の処理に移行する（ステップＳ３４）。
【００４８】
一方、上記ステップＳ２１において、「Ｎｏ」の場合、つまりＧデータ受信回数が「０」だった場合、ＣＰＵ４７は、図６のステップＳ３５に移行し、受信周期カウンタの残り時間が「０」より大きいか否かを判定する（ステップＳ３５）。このステップＳ３５において、「Ｙｅｓ」の場合（図８中のＴＥ期間に該当する場合）、ＣＰＵ４７は、エラーデータを受信したか否か（エラーデータが「０」以外か否か）を判定する（ステップＳ３６）。ＣＰＵ４７は、上記ステップＳ３６において「Ｙｅｓ」であれば、ノーコードデータを受信したか否かを判定し（ステップＳ３７）、上記ステップＳ３６において「Ｎｏ」であれば、図５のステップＳ４６の処理に移行する。
【００４９】
そして、ＣＰＵ４７は、上記ステップＳ３７において「Ｎｏ」であれば、ＬｏＧ異常コードを受信したか否かを判定し（ステップＳ３８）、上記ステップＳ３７において「Ｙｅｓ」であれば、図５のステップＳ４６の処理に移行する。そして、ＣＰＵ４７は、上記ステップＳ３８において「Ｎｏ」であれば、ＰＣＳセンサ１０の故障診断に使用するＨｉＧ異常フラグをオンにセットし（ステップＳ３９）、上記ステップＳ３８において「Ｙｅｓ」であれば、ステップＳ４０の処理に移行する。そして、ＣＰＵ４７は、ＨｉＧ受信フラグをオフにセットし（ステップＳ４０）、さらに、タイマ４２の受信周期カウンタをリセットして図５のステップＳ４６の処理に移行する（ステップＳ４１）。
【００５０】
一方、上記ステップＳ３５において、「Ｎｏ」の場合、つまりカウントダウンが開始されてから１００ｍｓ以上経過してもＧデータを受信できなかった場合（図８中のＴＦ期間に該当する場合）、ＣＰＵ４７は、ＨｉＧ異常フラグをオンにセットし（ステップＳ４２）、ＨｉＧ受信フラグをオフにセットし（ステップＳ４３）、さらに、エラーデータを受信したか否か（エラーデータが「０」以外か否か）を判定する（ステップＳ４４）。ＣＰＵ４７は、上記ステップＳ４４において「Ｙｅｓ」であれば、エラーデータを記録して図５のステップＳ４６の処理に移行し（ステップＳ４５）、上記ステップＳ４４において「Ｎｏ」であれば、図５のステップＳ４６の処理に移行する。
【００５１】
図５に戻り、ステップＳ３４の実行後、或いは図６で説明したＴＥ期間、ＴＦ期間に該当するステップＳ３５〜Ｓ４５の実行後、ＣＰＵ４７は、ＨｉＧ受信フラグがオンか否かを判定し（ステップＳ４６）、「Ｙｅｓ」であれば、実際の衝突判定に用いるＨｉＧ変数にセットすべき衝突判定データＧの算出処理を行い（ステップＳ４７）、「Ｎｏ」であれば、ＨｉＧ変数に代替値として「０」をセットする（ステップＳ４８）。
【００５２】
図７は、上述したＧデータ判別処理のステップＳ４７における衝突判定データ算出処理の詳細を示すフローチャートである。この図７に示すように、まず、ＣＰＵ４７は、今回のデータセットの中からＨｉＧデータと判別可能なＧデータを取得し（ステップＳ５１）、Ｇデータ受信回数が「４」と等しいか否かを判定する（ステップＳ５２）。
【００５３】
このステップＳ５２において、「Ｙｅｓ」の場合、つまり今回のデータセットの中からＨｉＧデータと判別可能なＧデータを４個取得できた場合、ＣＰＵ４７は、ＨｉＧ代替要求フラグをオフにセットし（ステップＳ５３）、衝突判定データＧを算出した後、衝突判定データ算出処理を終了する（ステップＳ５４）。具体的には、ＨｉＧデータと判別可能な４個のＧデータを、それぞれＤ１、Ｄ２、Ｄ３、Ｄ４とすると、この時の衝突判定データＧは下記（１）式で表される。
Ｇ＝Ｄ１＋Ｄ２＋Ｄ３＋Ｄ４＝Ｇave ・・・・（１）
【００５４】
一方、上記ステップＳ５２において、「Ｎｏ」の場合、ＣＰＵ４７は、Ｇデータ受信回数が「３」と等しいか否かを判定する（ステップＳ５５）。このステップＳ５５において、「Ｙｅｓ」の場合、つまり今回のデータセットの中からＨｉＧデータと判別可能なＧデータを３個取得できた場合、ＣＰＵ４７は、ＨｉＧ代替要求フラグをオフにセットし（ステップＳ５６）、衝突判定データＧを算出した後、衝突判定データ算出処理を終了する（ステップＳ５７）。具体的には、ＨｉＧデータと判別可能な３個のＧデータを、それぞれＤ１、Ｄ２、Ｄ３とすると、この時の衝突判定データＧは下記（２）式で表される。
Ｇ＝４×｛（Ｄ１＋Ｄ２＋Ｄ３）／３｝
＝４×Ｇave／３ ・・・・（２）
【００５５】
一方、上記ステップＳ５５において、「Ｎｏ」の場合、つまりＧデータ受信回数が「２」、「１」、「０」のいずれかである場合、ＣＰＵ４７は、ＨｉＧ代替要求フラグがオンにセットされているか否かを判定する（ステップＳ５８）。このステップＳ５８において、「Ｙｅｓ」の場合、つまりＨｉＧ代替要求フラグがオンの場合、ＣＰＵ４７は、衝突判定データＧに代替値として「０」をセットした後、衝突判定データ算出処理を終了する（ステップＳ５９）。一方、上記ステップＳ５８において、「Ｎｏ」の場合、つまりＨｉＧ代替要求フラグがオフの場合、ＣＰＵ４７は、衝突判定データＧを前回値のまま保持し（ステップＳ６０）、ＨｉＧ代替要求フラグをオンにセットした後、衝突判定データ算出処理を終了する（ステップＳ６１）。
【００５６】
以上説明したように、本実施形態におけるＥＣＵ４０によれば、１つのデータセット内に（つまり処理単位時間内に取得した受信データ中に）、ＬｏＧデータと判別可能なＧデータ（最初のＧデータ）と、ＨｉＧデータと判別可能なＧデータ（後続のＧデータ）とが混在する場合、ＬｏＧデータと判別可能なＧデータ、つまり最初のＧデータのみを破棄するため、データセット内に存在する有効なＨｉＧデータを衝突判定に用いることができ、衝突判定精度の向上を図ることが可能となる。
【００５７】
なお、本発明は上記実施形態に限定されず、以下のような変形例が考えられる。
（１）上記実施形態では、ＰＣＳ１０から送信されるシリアルデータに、８０ｍｓ周期で通信されるＬｏＧデータと、２５０μｓ周期で連続通信されるＨｉＧデータとが含まれている場合を想定して説明したが、これらの周期はあくまで一例であり、本発明はこれ以外の周期でＬｏＧデータ及びＨｉＧデータが送信される場合にも適用することができる。
【００５８】
（２）上記実施形態では、１つのデータセット内に、ＬｏＧデータと判別可能なＧデータと、ＨｉＧデータと判別可能なＧデータとが混在する場合、ＬｏＧデータと判別可能なＧデータ、つまり最初のＧデータのみを破棄するという基本原理を実現させるために、図４〜図７に示すサンプリングデータ判別処理及びＧデータ判別処理を用いたが、これらの処理はあくまで基本原理を実現させるための一例に過ぎず、基本原理を実現可能であれば、他の処理を用いても良い。
【００５９】
（３）図９で示した歩行者保護システムは、あくまでＥＣＵ４０を適用可能なシステムの一例であり、車種、ＰＣＳ１０の種類、個数は図９のシステムに限定されず、様々なシステム構成に対して本発明に係る電子制御装置を適用可能であることは勿論である。
【符号の説明】
【００６０】
１００…車両、１１０…フロントバンパ、１３０…エンジンフード、１５０…セーフティプレート、１０Ｌ、１０Ｃ、１０Ｒ、１０…歩行者衝突センサ（ＰＣＳ）、２０…車速センサ、３０、４０…ＥＣＵ（Electronic Control Unit：電子制御装置）、４１…通信インタフェース、４２…タイマ、４３…ＲＯＭ(Read Only Memory)、４４…ＲＡＭ(Random Access Memory)、４６…パワーユニット駆動回路、４７…ＣＰＵ(Central Processing Unit：データ処理部)、８０…パワーユニット、１８０…エンジンフード
【特許請求の範囲】
【請求項１】
第１周期で受信した加速度データを低加速度データと判別し、前記第１周期より短い第２周期で受信した加速度データを高加速度データと判別する電子制御装置であって、
処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データと、前記高加速度データと判別可能な加速度データとが混在する場合、前記低加速度データと判別可能な加速度データを破棄するデータ処理部を備えることを特徴とする電子制御装置。
【請求項２】
前記データ処理部は、前記処理単位時間内に取得した受信データから前記低加速度データと判別可能な加速度データを破棄した後、残った加速度データを前記高加速度データとして用いることを特徴とする請求項１記載の電子制御装置。
【請求項３】
前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記低加速度データとして用いることを特徴とする請求項１または２に記載の電子制御装置。
【請求項４】
前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記高加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記高加速度データとして用いることを特徴とする請求項１〜３のいずれか一項に記載の電子制御装置。
【請求項１】
第１周期で受信した加速度データを低加速度データと判別し、前記第１周期より短い第２周期で受信した加速度データを高加速度データと判別する電子制御装置であって、
処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データと、前記高加速度データと判別可能な加速度データとが混在する場合、前記低加速度データと判別可能な加速度データを破棄するデータ処理部を備えることを特徴とする電子制御装置。
【請求項２】
前記データ処理部は、前記処理単位時間内に取得した受信データから前記低加速度データと判別可能な加速度データを破棄した後、残った加速度データを前記高加速度データとして用いることを特徴とする請求項１記載の電子制御装置。
【請求項３】
前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記低加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記低加速度データとして用いることを特徴とする請求項１または２に記載の電子制御装置。
【請求項４】
前記データ処理部は、前記処理単位時間内に取得した受信データ中に、前記高加速度データと判別可能な加速度データのみが存在する場合、当該加速度データを前記高加速度データとして用いることを特徴とする請求項１〜３のいずれか一項に記載の電子制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１１−９８６９４（Ｐ２０１１−９８６９４Ａ）
【公開日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願番号】特願２００９−２５６１２５（Ｐ２００９−２５６１２５）
【出願日】平成２１年１１月９日（２００９．１１．９）
【出願人】（０００１４１９０１）株式会社ケーヒン (1,140)
【Ｆターム（参考）】
【公開日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願日】平成２１年１１月９日（２００９．１１．９）
【出願人】（０００１４１９０１）株式会社ケーヒン (1,140)
【Ｆターム（参考）】
[ Back to top ]