車両制御システム
【課題】車両制御の機能に応じて設定されるライフサイクルに基づいて、車両制御の処理単位を適切に変更する車両制御システムを提供する。
【解決手段】機能ドメインＥＣＵ２００、２０２、２０４、２０６は、機能ドメイン毎に、制御対象の挙動を制御する制御処理を実行する。イントラボックス１００の実行管理手段１１０は、エンジンの始動、停止に伴う車両制御の起動時および終了時において、機能ドメインＥＣＵが実行する制御処理、ならびにイントラボックス１００の共通処理手段１２０が実行する車両制御の共通処理の実行順序を管理する。車両制御の処理は、パラメータ記憶手段１１２に記憶されているパラメータに基づいて設定されるライフサイクルの長さに基づいて分類されている。例えば、イントラボックス１００が実行するバッテリの電気特性に基づく電力管理処理のライフサイクルは、機能ドメインＥＣＵが実行する車両の駐車アシスト処理よりも長い。
【解決手段】機能ドメインＥＣＵ２００、２０２、２０４、２０６は、機能ドメイン毎に、制御対象の挙動を制御する制御処理を実行する。イントラボックス１００の実行管理手段１１０は、エンジンの始動、停止に伴う車両制御の起動時および終了時において、機能ドメインＥＣＵが実行する制御処理、ならびにイントラボックス１００の共通処理手段１２０が実行する車両制御の共通処理の実行順序を管理する。車両制御の処理は、パラメータ記憶手段１１２に記憶されているパラメータに基づいて設定されるライフサイクルの長さに基づいて分類されている。例えば、イントラボックス１００が実行するバッテリの電気特性に基づく電力管理処理のライフサイクルは、機能ドメインＥＣＵが実行する車両の駐車アシスト処理よりも長い。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載された制御対象の挙動を制御する車両制御システムに関する。
【背景技術】
【０００２】
車両に搭載された制御対象の挙動を制御する車両制御を複数の制御処理に分類して実行する車両制御システムが知られている（例えば、特許文献１、２参照。）。分類された制御処理については、各マイクロコンピュータ（以下、マイコンとも言う。）が一つの制御処理を実行してもよいし、一つのマイコン内に設けた複数のプログラムモジュールがそれぞれ制御処理を実行することにより、一つのマイコンが複数の制御処理を実行してもよい。このように、車両制御を複数の制御処理に分類することにより、マイコン単位、またはマイコン内でのモジュール単位での変更が容易になる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−１０４１８９号公報
【特許文献２】特開２００１−２３９９０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、制御処理の分類の仕方によっては、一つの制御処理内に車両における存続期間であるライフサイクルの異なる処理が混在することがある。例えば、電源であるバッテリが鉛バッテリであるか、リチウムイオンバッテリであるかという、バッテリの発生電圧、充放電時間等の電気特性に基づく電力管理処理のライフサイクルは、車両のライフサイクルと同じか、またはそれ以上である。車両のライフサイクルとは、その車種の車両の製造が開始されてから終了するまでの期間を表している。したがって、バッテリ自体が製品寿命による劣化等により新しい同じバッテリに交換されても、バッテリの電気特性に基づく制御処理としての電力管理処理は、該当バッテリを搭載する車両が製造されている間は変更する必要がない。
【０００５】
一方、同じ電力管理処理において、車両に搭載されている個々の制御対象に電力を供給する電力供給に関する電力管理処理は、同じ車種であってもオプション製品の有無、モデルチェンジによる車載製品の変更等により、車両の製造期間中に変化する。つまり、電力管理において、バッテリの電気特性に基づく電力管理処理のライフサイクルの長さと、電力供給に関する電力管理処理のライフサイクルの長さとは異なっている。
【０００６】
このように、ライフサイクルの異なる制御処理を、単に電力管理として同じ制御処理に分類すると、オプション製品の追加、削除等により電力供給の電力管理処理を変更しなければならないときに、変更する必要のないバッテリの電気特性に基づく電力管理処理も変更されるという問題がある。
【０００７】
このように、変更する必要のないライフサイクルの長い制御処理をライフサイクルの短い制御処理と一緒に変更すると、ライフサイクルの長い制御処理のアルゴリズムが不必要に変更されることがある。その結果、同じアルゴリズムで制御処理を続ければアルゴリズムの問題点が解消される機会が増加するにも関わらず、その機会が低減するという問題が生じる。
【０００８】
本発明は、上記問題を解決するためになされたものであり、車両制御の機能に応じて設定されるライフサイクルに基づいて、車両制御を構成する制御処理を適切なタイミングで変更する車両制御システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
請求項１から１８に記載の発明によると、車両制御システムは、車両に搭載された複数の制御対象の挙動を制御するために複数の制御処理からなる車両制御を実行する制御処理手段と、車両制御のライフサイクルを車両制御の機能に応じて設定するパラメータを記憶しているパラメータ記憶手段と、を備え、制御処理は、パラメータにより設定されるライフサイクルの長さに基づいて分類されている。
【００１０】
これにより、パラメータ記憶手段に記憶されているパラメータにより設定された制御処理のライフサイクルの長さに基づいて、制御処理を適切なタイミングで変更できる。したがって、ライフサイクルが異なり変更不要な制御処理を変更することを防止できる。
【００１１】
このパラメータ記憶手段は、車両オンボード上で、パラメータによる分類がされれば、ライフサイクル毎の制御処理配置を後付の製品まで対象を拡大できるが、明らかにライフサイクルが定義される正規のオプション製品を含めた車両に標準装備される処理装置に限定すれば、車両オフボードで例えば設計段階もしくは車両ディーラでの限定的な取り扱いにおいて、ライフサイクル毎の制御処理配置集約を可能とする。
【００１２】
また、本発明ではパラメータをライフサイクル相違判断基準とした。パラメータとしては、ライフサイクルを判別するための手段、例えば処理装置における所定の電圧による記憶であったり、制御処理のプログラム実装領域であったり、制御処理のＡＰＩであったり等、何らかの判断が可能な手段であればよい。
【００１３】
また、パラメータは必ず一致しなくとも、ある範囲内、例えば車両のモデルチェンジよりは十分に長いものを一つのくくりにしてもよい。これにより不要に多くのライフサイクル分割を防止する。
【００１４】
また、ライフサイクルの長い制御処理は長く使用されるので、同じアルゴリズムが長く使用される。これにより、ライフサイクルの長い制御処理のアルゴリズムの問題点が解決される機会が増えるので、ライフサイクルの長い制御処理のアルゴリズムの信頼性が向上する。
【００１５】
ここで、ライフサイクルに応じて制御処理を変更する車両制御システムにおいて、制御処理を実行するハードウェアとしての処理装置を設ける場合、制御処理毎に処理装置が設けられてもよいし、複数の制御処理を同じライフサイクル毎に各処理装置に振り分けてもよいし、異なるライフサイクルの制御処理を同じ処理装置が実行してもよい。処理装置としては、例えばＣＰＵ、ＲＯＭ、ＲＡＭ等から構成されるマイコンが考えられる。
【００１６】
これにより、例えば車のモデルチェンジよりライフサイクルの長い制御処理が集約されていれば、このようなライフサイクルの長い制御処理を実行する処理装置が多種の車両モデルで共通利用できるので、車両メーカおよび部品メーカは自社の部品品番数を大幅に削減でき、１製品としての製品ライフサイクルを可能な限り延命することが可能になる。
【００１７】
さらに、近年車両使用年数が長期化する一方で、電子製品数の増加、ＣＰＵ等の電子部品の機能向上による部品ライフサイクルの短寿命化により電子製品の交換部品が入手困難のために車両修理が出来なくなる可能性を低減し、中古市場での部品調達が容易になる。これは引いては、車両廃棄の削減や中古電子処理装置の廃棄量を抑制する環境保護にも寄与する。
【００１８】
ここで、更にライフサイクルの長い制御処理がＣＰＵ等の電子部品の機能向上を考慮しアッパーコンパチで設計されれば、中古電子処理装置の再利用に留まらず、中古車両での新規処理装置による修理も可能になるので、リサイクル率の向上による環境保護にも寄与する。ここで言う環境保護は、廃棄物の処理だけの視点でなく、新たな物を余分に作り出さない意味でも考慮されるので、ＣＯ2削減効果にも寄与する。
【００１９】
これらの処理装置の再利用が向上する効果は、車両メーカや部品メーカの開発工数低減にも寄与する。まず単純に部品品番削減から開発する部品数が削減するだけでなく、通常車両毎に評価される評価を、イニシャルで切り替えた車両評価結果を部分的に継承できるので、開発期間の短縮にも寄与することになる。
【００２０】
また、異なるライフサイクルの制御処理を実行する処理プログラムを同じＲＯＭまたはフラッシュメッモリ等の記憶装置に記憶する場合、各処理プログラムをモジュール化し、異なる記憶領域に記憶する構成が考えられる。この場合、ライフサイクルに応じて、該当する記憶領域の処理プログラムだけを変更すればよい。
【００２１】
これにより、特に車両モデルチェンジと異なる長いライフサイクルと短いライフサイクルを混在させれば、ライフサイクルの相違による部品品番を増加させることなく、車両モデルチェンジに依存しない再利用可能な部品を全て集約可能になる。その結果、車両の部品構成において、購買者の嗜好に沿ったモデルチェンジ毎に変化するライフサイクル機能とは別に、購買者の嗜好とは関係ない機能集約が容易に進む。
【００２２】
即ち、車両の処理装置点数の増加は、言い換えれば購買者の嗜好変化に合わせて、従来提供された機能に対して車両機能が追加された、もしくは進化した結果であり、これに嗜好変化に影響しない機能が混在実装されることで、処理装置の再利用を阻んできた。
【００２３】
しかし、本発明により、購買者の嗜好を実現する機能と嗜好に関わらない機能とが分離可能となったため、従来は処理装置の再利用は嗜好変化を無視するしかなかったため、結局なかなか処理装置の再利用は進まず類似品が作られる結果に終わったが、初めて、本当に購買者の嗜好変化を局所化し、嗜好変化に応じつつも、単に１車両の処理装置点数だけでなく、車両メーカ全体の品番点数を押し下げる効果を発揮することができる。
【００２４】
また、プログラム開発環境として、例えばＭＡＴＬＡＢ（登録商標）等を使用して車両制御システムのモデルを設定する場合に、機能単位として異なるライフサイクルの制御処理のブロックを設定してプログラムコードを自動生成することも考えられる。ライフサイクルに応じて制御処理が変更になると、該当する制御処理のブロックは機能設定を変更し、変更されなかった制御処理のブロックは機能設定を変更しない。プログラムコードを自動生成する場合、ライフサイクルの異なる制御処理の処理プログラムがどのような記憶領域に配置されるかは、自動コード生成の仕様によるので予測できない。
【００２５】
請求項２に記載の発明によると、複数の制御対象は制御対象の機能に応じて分類された機能ドメインに統合されており、制御処理のライフサイクルの長さは機能ドメイン毎にパラメータにより設定されている。制御対象の機能とは、車両における制御対象の役割であり、例えばトルク発生系、制動系、娯楽情報系等に分類することができる。
【００２６】
機能ドメインは制御対象の機能に応じて複数の制御対象を分類して構成されているので、制御対象の機能に基づいて機能ドメイン毎に制御処理のライフサイクルが設定されることが望ましい。
【００２７】
請求項３に記載の発明によると、機能ドメインは制御対象の機能に応じて機能ドメインよりも詳細なサブドメインに分類されており、制御処理のライフサイクルの長さはサブドメイン毎にパラメータにより設定されている。
【００２８】
これにより、制御対象の機能に応じて機能ドメインよりも詳細に分類されたサブドメインに対し、詳細にライフサイクルを設定できる。
ところで、ユーザの嗜好、流行等に基づく車両に対するユーザのニーズは、制御対象である車載製品毎に異なる。例えば、バッテリの機能に対するユーザのニーズは低いので、バッテリに対する制御処理のライフサイクルは車両のライフサイクル以上であることが多い。これに対し、車両の安定走行の向上に対するユーザのニーズは高いので、車両のライフサイクル中であっても、ブレーキの制動力制御とインジェクタの噴射制御との連携制御を、１回または数回のモデルチェンジ毎に変更することがある。
【００２９】
そこで、請求項４に記載の発明によると、制御処理のライフサイクルの長さは、ユーザのニーズに基づいてパラメータにより設定されている。
これにより、ユーザのニーズが高い制御処理についてはライフサイクルを短くし、ニーズが低い制御処理についてはライフサイクルを長くすればよい。その結果、ユーザのニーズに応じてパラメータにより設定されたライフサイクル毎に、適切に制御処理を変更できる。
【００３０】
請求項５に記載の発明によると、車両制御に共通する少なくとも一つの共通処理を実行する共通処理手段をさらに備えている。そして、共通処理は、共通処理の機能に応じてパラメータにより設定された共通処理のライフサイクルの長さに基づいて分類されている。
【００３１】
制御対象に対する制御対象特有の車両制御とは異なり、車両制御に共通する少なくとも一つの共通処理を実行する共通処理手段を制御処理手段とは別に設けることにより、車両制御のうち共通処理と、それ以外の制御処理とを、それぞれの機能に応じたライフサイクルにより適切に分類できる。
【００３２】
また、車両制御に共通する共通処理は、車種に関わらずに共通な処理であることが多いので、異なる車種において同じ共通処理を使用できる。その結果、共通処理の再利用性が向上する。
【００３３】
請求項６に記載の発明によると、共通処理のライフサイクルの長さは、技術的なライフサイクルに基づいてパラメータにより設定されている。
ユーザの嗜好、流行等に基づく車両に対するユーザのニーズは、通常、制御対象の機能毎に異なっている。これに対し、車両制御に共通する共通処理は、ユーザのニーズとは異なり、技術的な観点からライフサイクルが設定されることが多い。したがって、車両制御に共通する共通処理のライフサイクルの長さを技術的なライフサイクルに基づいてパラメータが設定することにより、共通処理を、ユーザのニーズに関わらず技術的な観点により分類できる。
【００３４】
請求項７に記載の発明によると、複数の共通処理の一つは、制御対象の挙動が正常であるか異常であるかを判定し、異常である場合に制御処理手段による制御対象に対する制御指令値を補正する監査処理である。
【００３５】
制御対象の挙動が正常であるか異常であるかを判定し、挙動が異常の場合に制御対象に対する制御指令値を補正することにより制御対象の挙動を適切に制御する監査処理は、車両のモデルチェンジ等に関わらず、車両制御に共通の処理である。したがって、監査処理を共通処理の一つとすることにより、他の処理の変更による監査処理に対する影響を排除できる。
【００３６】
請求項８に記載の発明によると、複数の共通処理の一つは、車両情報の安全性を管理する情報管理処理である。
例えば、車両制御システムにおいて、メモリの不正な入れ替え等により処理プログラムが不正に改竄されていないか、処理プログラムがウィルスに感染していないか、車両所有者を認識するための個人情報の開示制限など、車両情報を管理する情報管理処理は、車両制御に共通の処理である。そして、このような情報管理処理は、技術的な進歩に応じて速やかに変更される必要がある。したがって、情報管理処理を共通処理の一つとすることにより、他の処理の変更による情報管理処理に対する影響を排除するとともに、情報管理処理を技術的な進歩に応じて速やかに変更できる。
【００３７】
請求項９に記載の発明によると、複数の共通処理の一つは、制御処理手段において変更可能なハードウェアまたはソフトウェアを特定する照合情報に基づいてハードウェアまたはソフトウェアの変更が適正であるか否かを判定する変更判定処理であり、変更判定処理のライフサイクルは照合情報のライフサイクルよりも長い。
【００３８】
ハードウェアまたはソフトウェアの変更が適正であるか否かの変更判定処理は、車両制御に共通の処理である。したがって、ハードウェアまたはソフトウェアの変更が適正であるか否かの判定処理を共通処理の一つとすることにより、他の処理の変更による変更判定処理に対する影響を排除できる。
【００３９】
尚、変更可能なハードウェアまたはソフトウェアを特定する照合情報としては、ハードウェアおよびソフトウェアのバージョン、製造会社等が考えられる。そして、照合情報は、新製品の開発等に応じて逐次更新される必要があるので、そのライフサイクルは短い。一方、照合情報に基づく変更可否の判定処理は信頼性を要求されるので、照合情報よりも長いライフサイクルが設定されている。
【００４０】
請求項１０に記載の発明によると、複数の共通処理の一つは、制御処理手段におけるハードウェアまたはソフトウェアの変更が適正である場合、制御処理手段が接続する通信系の通信設定を調整する通信設定処理である。
【００４１】
制御処理手段においてハードウェアまたはソフトウェアが適正に変更されると、制御処理手段が接続する通信系の通信設定を制御処理手段の変更に基づいて調整する必要がある。そして、通信設定を調整する通信設定処理は、車両制御に共通の処理である。したがって、通信設定処理を共通処理の一つとすることにより、他の処理の変更による通信設定処理に対する影響を排除できる。
【００４２】
ところで、電力および熱等の車両におけるエネルギーの生成、保存および消費等のエネルギー管理は、各エネルギーの時定数を考慮し、車両全体の観点から実行する必要がある。
【００４３】
そこで、請求項１１に記載の発明によると、複数の共通処理の一つは、車両におけるエネルギーを管理する車上エネルギー管理処理である。これにより、個々の制御対象に対する制御処理とは別に、エネルギー管理を車両全体の観点から実行できる。
【００４４】
請求項１２に記載の発明によると、複数の共通処理の一つは、制御処理手段に搭載された電子製品の余剰資源を管理する電子製品管理処理である。
これにより、オプション製品の追加、ソフトウェアまたはハードウェアのバージョンアップ等が実施される場合に、既存の搭載製品の余剰資源として、例えば、処理能力に余裕のあるＣＰＵに追加処理の一部を割り当てたり、未使用のメモリ領域を追加処理に割り当てることができる。その結果、新たな電子製品の追加を極力低減し、電子製品の資源の観点から車両制御システムのライフサイクルを極力延ばすことができる。
【００４５】
請求項１３に記載の発明によると、共通処理のライフサイクルは、車両のライフサイクル以上のロングサイクルと、車両のライフサイクルよりも短いショートサイクルとに分かれており、さらにショートサイクルの長さに基づいて共通処理が分類されている。
【００４６】
車両のライフサイクルよりも短いショートサイクルの共通処理は、車両のライフサイクル中に少なくとも１回変更される。したがって、ショートサイクルの長さに基づいて共通処理を分類することにより、ショートサイクルの共通処理において、不要な処理の変更を防止できる。
【００４７】
一方、車両のライフサイクル以上のロングサイクルの共通処理は、車両のライフサイクル中に変更する必要がなく、車両と同じライフサイクルと見なすことができる。したがって、車両のライフサイクル以上のロングサイクルの共通処理と、車両のライフサイクルよりも短いショートサイクルの共通処理とに分類することにより、ショートサイクルの共通処理の変更の影響を受けることなく、ロングサイクルの共通処理の信頼性を向上できる。
【００４８】
請求項１４に記載の発明によると、共通処理手段のうち、ロングサイクルの共通処理を実行する部分は、一つの処理装置に統合されている。
このように、ロングサイクルの共通処理を実行する共通処理手段の部分をショートサイクルの共通処理を実行する共通処理手段の部分から分離して一つの処理装置に統合することにより、ロングサイクルの共通処理を実行する共通処理手段の部分を統合した処理装置を全ての車両に共通して使用できる。その結果、処理装置のコストを低減できる。また、ショートサイクルの共通処理の変更が容易になる。
【００４９】
請求項１５に記載の発明によると、一つの処理装置に統合された共通処理手段のうち、冗長性が要求される部分をさらに別の処理装置に統合して冗長系を構成する。
これにより、ロングサイクルの共通処理を実行する共通処理手段の部分を統合した一つの処理装置が故障しても、別の処理装置により冗長性が要求される重要なロングサイクルの共通処理を実行できる。その結果、車両制御に必須の冗長性が要求されるバッテリ管理等のロングサイクルの共通処理が停止することを防止できる。
【００５０】
ところで、車両制御においてライフサイクルの長い処理は、エンジンを始動してから停止するまでの１トリップ中においても、実行を開始してから終了するまでの期間がライフサイクルの短い処理よりも長い。それは、通常、ライフサイクルの長い処理は、ライフサイクルの短い処理よりも処理範囲が広く、ライフサイクルの短い処理の実行環境を整備するからである。
【００５１】
例えば、電源管理処理は、電源管理処理よりもライフサイクルの短い他の制御処理よりも先に起動して電力供給を制御する必要があるし、他の制御処理が終了する前に電力供給制御を終了することはできない。したがって、ライフサイクルの長さに応じて処理の実行順序を適切に管理しないと、車両制御を正常に実行できないという問題が生じる。
【００５２】
そこで、請求項１６に記載の発明によると、車両制御の実行を管理する実行管理手段をさらに備え、実行管理手段は、ライフサイクルに基づいて車両制御を実行する処理の実行順序を管理し、車両制御の起動時には、ライフサイクルの長い処理をライフサイクルの短い処理よりも先に起動し、前記車両制御の終了時には、ライフサイクルの長い処理をライフサイクルの短い処理よりも後に終了させる。
【００５３】
これにより、車両制御の起動時には、ライフサイクルの長い処理により車両制御の実行環境が整備されてからライフサイクルの短い処理を実行できるので、ライフサイクルの長い処理により車両制御の実行環境が整備される前にライフサイクルの短い処理が誤った制御および診断を実行することを防止できる。
【００５４】
また、車両制御の終了時には、ライフサイクルの長い処理の終了により車両制御の実行環境が解消される前にライフサイクルの短い処理を終了できるので、車両制御の実行環境が解消された状態でライフサイクルの短い制御処理が誤った制御および診断を実行することを防止できる。一方、ライフサイクルの長い処理は、ライフサイクルの短い処理の実行が終了してから、記憶する必要のある情報をフラッシュメモリに書き込むなど、適切な終了処理を実行してから自身を終了する。
【００５５】
ところで、車両制御の実行中に、車両制御を実行する処理のうちいずれかの処理が異常発生等によりリセットされることがある。この場合、リセットされた処理よりもライフサイクルの長い処理は、リセットされた処理の実行環境に関わらずに正常に処理を継続できる。一方、リセットされた処理よりもライフサイクルの短い処理は、リセットされた処理の実行環境の元で実行されることが多いので、リセットされた処理の実行が再開されるまでの間は、正常に処理を実行できないことがある。
【００５６】
そこで、請求項１７に記載の発明によると、実行管理手段は、車両制御を実行する処理のうちいずれかの処理がリセットされると、リセットされた処理の実行が再開されるまで、リセットされた処理よりもライフサイクルの短い処理の実行を待機させる。
【００５７】
これにより、リセットされた処理の実行が再開され、リセットされた処理により整備された実行環境の元で、リセットされた処理よりもライフサイクルの短い処理を実行できる。
【００５８】
請求項１８に記載の発明によると、車両制御を実行する処理手段は同じライフサイクルの車両制御を実行する制御処理毎にオブジェクト化されている。これにより、ライフサイクルに応じて、車両制御の変更がオブジェクト単位で容易になる。
【００５９】
尚、本発明に備わる複数の手段の各機能は、構成自体で機能が特定されるハードウェア資源、プログラムにより機能が特定されるハードウェア資源、またはそれらの組み合わせにより実現される。また、これら複数の手段の各機能は、各々が物理的に互いに独立したハードウェア資源で実現されるものに限定されない。
【図面の簡単な説明】
【００６０】
【図１】第１実施形態の車両制御システムを示すブロック図。
【図２】パラメータ記憶手段に記憶されているパラメータを示す模式図。
【図３】ライフサイクルに応じて設定された車両制御の分類図。
【図４】共通処理の分類を示すブロック図。
【図５】共通処理のうち監査処理を示すブロック図。
【図６】共通処理のうち情報管理処理を示すブロック図。
【図７】共通処理のうち変更判定処理を示すブロック図。
【図８】共通処理のうち車上エネルギー管理処理を示すブロック図。
【図９】共通処理のうち電子製品管理処理を示すブロック図。
【図１０】イントラボックスの構成例を示すブロック図。
【図１１】イントラボックスの構成例を示すブロック図。
【図１２】オブジェクト化された処理手段を示すシステム図。
【図１３】実行管理ルーチン１を示すフローチャート。
【図１４】実行管理ルーチン２を示すフローチャート。
【図１５】第２実施形態の車両制御システムを示すブロック図。
【発明を実施するための形態】
【００６１】
以下、本発明の実施の形態を図に基づいて説明する。
［第１実施形態］
本発明の第１実施形態による車両制御システムを図１に示す。
【００６２】
（車両制御システム１０）
車両制御システム１０は、パワートレイン(Power Train)ＥＣＵ(Electronic Control Unit)２０、シャーシ(Chassis)ＥＣＵ３０、ボディ(Body)ＥＣＵ４０、インフォテインメント(Infotainment)ＥＣＵ５０、イントラボックス(Intra Box)１００等から構成されている。パワートレインＥＣＵ２０、シャーシＥＣＵ３０、ボディＥＣＵ４０、インフォテインメントＥＣＵ５０は、それぞれ車両に搭載されている制御対象の機能、言い換えれば車両における制御対象の役割に応じて分類された機能ドメインであるパワートレインドメイン、シャーシドメイン、ボディドメイン、インフォテインメントドメイン毎に、制御対象の挙動を制御するための制御処理を機能ドメイン単位で実行する機能ドメインＥＣＵである。各機能ドメインＥＣＵには、制御対象の挙動を制御する複数の制御処理を実行する制御処理手段２２、３２、４２、５２が設けられている。
【００６３】
各機能ドメインは、制御対象の機能に応じて機能ドメインよりも詳細なサブドメインに分類されている。そして、これらサブドメイン毎に制御対象の挙動を制御するサブドメインＥＣＵ２４、３４、４４、５４が各機能ドメインＥＣＵに接続している。
【００６４】
パワートレインＥＣＵ２０とシャーシＥＣＵ３０とボディＥＣＵ４０とインフォテインメントＥＣＵ５０とイントラボックス１００とは、例えばＦｌｅｘＲａｙ（Daimler Chrysler社の登録商標）による車内ネットワーク３００により互いに通信可能に接続されており、各機能ドメインＥＣＵとそのサブドメインＥＣＵとはＣＡＮ（Controller Area Network）、ＭＯＳＴ(Media Oriented Systems Transport)等による車内ネットワーク３１０により互いに通信可能に接続されている。車内ネットワーク３００と車内ネットワーク３１０とは、同じ形式のネットワークでもよい。
【００６５】
尚、機能ドメインの分類は上記に限るものではなく、機能ドメインに含まれる制御対象も種々の組み合わせが考えられる。また、すべての制御対象を機能ドメインに分類する必要はなく、一部の制御対象だけを機能ドメインに統合してもよい。また、機能ドメインが複数のサブドメインに分類されておらず、機能ドメインＥＣＵが機能ドメイン内のすべての制御対象の挙動を制御してもよい。
【００６６】
（制御処理手段）
パワートレインＥＣＵ２０の制御処理手段２２は、制御対象であるインジェクタ、変速機等の挙動をパワートレインドメイン単位で統合して制御する。
【００６７】
シャーシＥＣＵ３０の制御処理手段３２は、制御対象であるステアリング、ブレーキ等の挙動をシャーシドメイン単位で統合して制御する。
ボディＥＣＵ４０の制御処理手段４２は、制御対象である空調、ドア等の挙動をボディドメイン単位で統合して制御する。
【００６８】
インフォテインメントＥＣＵ５０の制御処理手段５２は、制御対象であるオーディオ装置、ナビゲーション装置等の挙動をインフォテインメントドメイン単位で統合して制御する。
【００６９】
サブドメインＥＣＵ２４、３４、４４、５４には、各機能ドメインを構成するサブドメインの制御対象の挙動を、例えば高圧ポンプの吐出量、左前輪ブレーキ、ステアリング、右前ドア、ＣＤプレイヤー毎に個別に制御する図示しない制御処理手段が設けられている。
【００７０】
各機能ドメインＥＣＵおよびサブドメインＥＣＵは、図示しないＣＰＵ、ＲＯＭ、ＲＡＭ、およびフラッシュメモリ等からなるマイコンにより主に構成されている。
機能ドメインＥＣＵおよびサブドメインＥＣＵに設けられた制御処理手段は、機能ドメイン毎に制御対象に対して複数の制御処理を実行する。そして、これら複数の制御処理は、車両制御の機能に応じて分類された制御処理のライフサイクルの長さに基づいて設定されている。そして、個々の機能ドメインに対する車両制御に応じて大まかなライフサイクルの範囲が設定されており、さらに機能ドメインを構成するサブドメインに対する車両制御に応じて詳細なライフサイクルが設定されている。尚、同じライフサイクルであれば、同じ機能ドメインの異なるサブドメインであっても、例えば、ブレーキ制御処理とステアリング制御処理とを同じ制御処理にしてもよい。
【００７１】
イントラボックス１００は、実行管理手段１１０、パラメータ記憶手段１１２、および共通処理手段１２０等から構成されている。実行管理手段１１０、パラメータ記憶手段１１２および共通処理手段１２０は、図示しないＣＰＵ、ＲＯＭ、ＲＡＭ、およびフラッシュメモリ等からなるマイコンにより主に構成されている。本実施形態では、イントラボックス１００を構成する処理装置としてのマイコンは、機能ドメインＥＣＵ、サブドメインＥＣＵとは異なる独立したマイコンである。
【００７２】
（実行管理手段１１０）
イントラボックス１００の実行管理手段１１０は、エンジンの始動、停止に伴う車両制御の起動時および終了時において、機能ドメインＥＣＵおよびサブＥＣＵの制御処理手段が実行する複数の制御処理、ならびにイントラボックス１００の共通処理手段１２０が実行する複数の共通処理の実行順序を、車両全体の観点から管理する。イントラボックス１００の共通処理手段１２０が実行する共通処理の詳細については後述する。
【００７３】
実行管理手段１１０は、車両制御の起動時には、制御処理および共通処理通のうち、ライフサイクルの長い処理をライフサイクルの短い処理よりも先に起動する。ライフサイクルの長い処理は、車両制御の実行環境を整える処理が多いので、ライフサイクルの長い処理を起動し、車両制御の実行環境を整えてからライフサイクルの短い処理を起動する。これにより、車両制御の実行環境が整えられてからライフサイクルの短い処理を起動できる。
【００７４】
実行管理手段１１０は、車両制御の終了時には、制御処理および共通処理通のうち、ライフサイクルの長い処理をライフサイクルの短い処理よりも後に終了させる。これにより、車両制御の実行環境が整えられた状態でライフサイクルの短い処理を終了させることができる。
【００７５】
ここで、エンジン停止後の蒸発燃料のリークチェックのように、エンジンのスタートスイッチがオフされてから所定時間経過後にソークタイマによりＥＣＵを起動することがある。このように、スタートスイッチオフ後において起動される車両制御においても、ライフサイクルの長い制御処理を起動して車両制御の実行環境を整えてから、ライフサイクルの短い処理を起動する。
【００７６】
例えば、エンジン停止後の蒸発燃料のリークチェックのために電磁弁を駆動する場合、バッテリの充電残量をチェックする処理により電磁弁の駆動が可能と判断されてから、リークチェック処理が起動され、電磁弁に電力が供給される。この場合、バッテリの充電残量管理処理のライフサイクルが一番長く、リークチェック処理、電磁弁への電力供給処理の順にライフサイクルが短くなる。
【００７７】
また、実行管理手段１１０は、車両制御中に、制御処理および共通処理のうちいずれかの処理に異常等が発生しリセットされると、リセットされた処理よりもライフサイクルの短い処理の実行を一旦停止させ待機させる。これは、リセットされた処理よりもライフサイクルの短い処理は、リセットされた処理の実行環境の元で実行されることがあるので、リセットされた処理の実行が再開されるまでの間は、正常に処理を実行できないことがあるからである。これに対し、リセットされた処理よりもライフサイクルの長い処理は、リセットされた処理の実行環境に関わらずに正常に処理を継続できる。
【００７８】
そして、実行管理手段１１０は、リセットされた処理の実行が再開されると、リセットされた処理よりもライフサイクルの短い処理の実行を許可する。これにより、リセットされた処理が再開され実行環境が整えられた状態で、リセットされた処理よりもライフサイクルの短い処理を実行できる。
【００７９】
（パラメータ記憶手段１１２）
図２に示すように、パラメータ記憶手段１１２は、例えば書き換え可能なメモリ装置としてフラッシュメモリにより構成されている。図２に示すように、パラメータ記憶手段１１２には、車両制御を構成する複数の制御処理と、各制御処理が車両に搭載された搭載開始時期と、車両に搭載可能な期間と、使用可能回数とが記憶されている。制御処理のライフサイクルとして、制御処理の機能に応じて、搭載開始時期と搭載可能期間、ならびに使用可能回数の少なくともいずれか一方がパラメータとして設定されている。搭載開始時期と搭載可能期間または使用可能回数の一方だけを設定する場合は、設定されないパラメータの欄には、初期値として例えば０が設定される。
【００８０】
搭載開始時期と搭載可能期間とにより、対象となる制御処理の搭載期間が終了し制御処理を変更するタイミングを知ることができる。また、使用可能回数は、制御処理の起動から終了を１回とし、初期に設定した使用可能回数から使用毎にカウントダウンすることにより、制御処理の変更時期を知ることができる。
【００８１】
尚、制御処理を車両に搭載可能な期間とは、制御処理が挙動を制御する制御対象が異なる機能の制御対象に変更されるまでの期間を表している。例えば、後述する駐車アシスト処理であれば、駐車時に障害物を車載カメラで検知して報知するだけであったものが、モデルチェンジにより、ステアリングおよびブレーキの自動操作によるアシスト処理に変更されることがある。この場合、モデルチェンジまでの期間が搭載可能期間となる。
【００８２】
また、使用可能回数としては、例えばダウンロードした車両用のウィルスチェックプログラムの無料使用回数が１０回であれば、初回の使用可能回数として１０回が設定される。そして１０回使用すると、使用を停止するか、料金を支払って正規版を購入する必要がある。
【００８３】
ライフサイクルを設定するパラメータとして、上記以外にも、法規の切り替わり時期、最新バージョン、車両ソフトを管理するプラットホームの大幅な変更時期等を採用してもよい。
【００８４】
ライフサイクルを設定するパラメータは、例えば、ディーラ等において外部端末を接続するか、管理センターとの通信により最新情報に更新することができる。
（ライフサイクルに基づく制御処理の分類）
次に、車両制御の機能に応じて設定されたライフサイクルに基づく、制御処理の分類について説明する。
【００８５】
図３に示すように、パワートレインＥＣＵ２０、シャーシＥＣＵ３０、ボディＥＣＵ４０、インフォテインメントＥＣＵ５０に相当する機能ドメインＥＣＵ２００、２０２、２０４、２０６（図４参照）、サブドメインＥＣＵ、イントラボックス１００が実行する制御処理は、ライフサイクルの長さに応じて設定されている。図３では、サブドメインＥＣＵを省略している。また、図３の△は、車両のモデルチェンジのタイミングを示している。
【００８６】
例えば、前述した鉛バッテリであるか、リチウムイオンバッテリであるかという、バッテリの発生電圧、充放電時間等の電気特性に基づく電力管理処理のライフサイクルは、車両のライフサイクル以上である。したがって、バッテリの電気特性に基づく電力管理処理は、モデルチェンジがあっても変更されず、該当車両が製造されている間は同じ処理が実行される。
【００８７】
これに対し、車両を駐車するときのアシスト処理は、１回または数回のモデルチェンジ毎に変更されることがある。例えば、車両の発売当初は、駐車時に単に障害物を車載カメラで検知し、警報や音声で報知するだけであったものが、モデルチェンジにより、ステアリングおよびブレーキの自動操作によるアシスト処理に変更されることがある。したがって、駐車アシスト処理のライフサイクルは、バッテリの電気特性に基づく電力管理処理よりも短い。
【００８８】
駐車アシスト処理と同じく、１回または数回のモデルチェンジ毎に変更される処理として、車両の安定走行制御処理が考えられる。発売当初においては、ＡＢＳ(Anti-lock Brake System)によりブレーキのロック状態を回避してブレーキの制動力を確保するだけであったものが、モデルチェンジによりブレーキの制動力制御にインジェクタの噴射制御を加えたＥＳＰ(Electronic Stability Program)に変更されることがある。このように、ＡＢＳからＥＳＰに変更することにより、スピン等により車両コントロールが不安定になった状態でも、ブレーキ制御と噴射制御等をＥＣＵで実行し、車両コントロールが不安定な状態になることを回避できる。
【００８９】
駐車アシスト処理および車両の安定走行制御処理等は、ユーザの嗜好および流行等によりユーザのニーズが高い処理であるから、技術的な観点とは別に、ユーザのニーズに応じてライフサイクルが設定されることがある。
【００９０】
また、情報管理処理においては、車両情報へのアクセス管理処理のように、ウィルス検出プログラムの更新を随時実施するものがある。したがって、アクセス管理処理のライフサイクルは、駐車アシスト処理およびブレーキ制御処理のライフサイクルよりも短い。
【００９１】
（共通処理手段１２０）
図１に示すイントラボックス１００の共通処理手段１２０は、機能ドメインＥＣＵおよびサブドメインＥＣＵの制御処理手段が機能ドメイン単位およびサブドメイン単位で制御対象に対して実行する車両制御に共通する複数の共通処理を実行する。
【００９２】
図４に示すように、イントラボックス１００の共通処理手段１２０は、複数の共通処理として、監査処理を実行する監査手段１３０、情報管理処理を実行する情報管理手段１４０、変更判定処理を実行する変更判定手段１５０、車上エネルギー管理処理を実行する車上エネルギー管理手段１６０、電子製品の余剰資源を管理する電子製品管理手段１８０を有している。このような、車両制御に共通する共通処理は、通常、車種に関わらずに共通な処理であるため、異なる車種において同じ共通処理を使用できる。
【００９３】
（監査手段１３０）
図５に示すように、監査手段１３０は、機能ドメインＥＣＵ２００、２０２、２０４、２０６の挙動制御の異常を監査することにより、車両制御システム１０の観点から車両のグローバル挙動１３２の異常を判定し、グローバル診断１３４により異常原因を診断する。
【００９４】
グローバル挙動１３２は、機能ドメインＥＣＵ２００、２０２、２０４、２０６のうち複数の機能ドメインＥＣＵによる挙動制御の結果として生じる車両の挙動である。例えば、各タイヤに対するブレーキ制御およびインジェクタに対する噴射制御の結果として生じる車両の横ずれ、スピンがグローバル挙動１３２である。また、グローバル診断１３４は、グローバル挙動１３２の異常原因を、複数の機能ドメインＥＣＵによる挙動制御に基づいて診断する。例えば、各タイヤに対するブレーキ制御およびインジェクタに対する噴射制御が正常であっても、結果として車両がスピンする場合には、グローバル診断１３４はグローバル挙動１３２の異常と判定し、グローバル挙動１３２が正常になるようにブレーキおよびインジェクタに対する制御指令値の補正量を算出し、シャーシＥＣＵ３０およびパワートレインＥＣＵ２０に補正量に基づく制御を指令する。
【００９５】
このように、監査処理は、車両制御に共通する処理であり、高い信頼性を要求される監査処理の基本的な処理機能のライフサイクルの長さは車両のライフサイクル以上である。
（情報管理手段１４０）
図６に示すように、情報管理手段１４０は、個々の機能ドメインＥＣＵ２００、２０２、２０４、２０６において、または機能ドメインＥＣＵ間において、車両情報が適正に処理されているかを管理する。例えば、情報管理手段１４０は、メモリの不正な入れ替え等により処理プログラムが不正に改竄され、その結果として不正な情報が車内ＬＡＮにおいて送受信されていないかをチェックする不正改竄チェック１４２、あるいは、処理プログラムがウィルスに感染している結果、メモリの書き込み禁止領域に書き込み要求が実行されたかをチェックする不正アクセスチェック１４４を実行する。これ以外にも、情報管理手段１４０は、車両所有者を認識するための個人情報の開示制限などを実行する。
【００９６】
情報管理処理は車両制御に共通の処理であり、技術的な進歩が著しい分野である。したがって、情報管理処理は、技術的な進歩に応じて短いライフサイクルで速やかに変更される必要がある。そこで、情報管理処理を共通処理の一つとすることにより、他の処理の変更による情報管理処理に対する影響を排除するとともに、情報管理処理を技術的な進歩に応じて速やかに変更できる。
【００９７】
（変更判定手段１５０）
図７に示すように、変更判定手段１５０は、車両制御システム１０のシステム構成を管理する。図７において、符号２１０、２１２、２１４、２１６、２２０、２２２、２２４、２２６は、例えば機能ドメインＥＣＵを表している。
【００９８】
変更判定手段１５０は、機能ドメインＥＣＵ２１０、２１２の供給元１、２の違い、機能ドメインＥＣＵ２１４、２１６のオプション搭載の有無、機能ドメインＥＣＵ２２０の後付搭載、機能ドメインＥＣＵ２２２のうち一部のソフトウェア（ＳＷ）のＶ（バージョン）１．０からＶ１．１へのアップデート、不具合等によるＶ２．０の機能ドメインＥＣＵ２２４からＶ３．０の機能ドメインＥＣＵ２２６への製品の交換等を検出する。そして、変更判定手段１５０は、検出したシステム構成に応じて、各機能ドメインＥＣＵにおいて変更可能なハードウェアおよびソフトウェアの製品を特定する照合情報を記憶している。そして、照合情報に基づいて、変更のあった製品が適切に変更された製品であるか否かを判定する。適切に変更された場合、変更判定手段１５０は、変更された製品が接続する通信系の通信設定を調整する通信設定手段としても機能する。
【００９９】
変更可能なハードウェアおよびソフトウェアの製品を特定する照合情報は、常に新しい情報に変更される必要がある。一方、照合情報に基づいて変更が適正であるか否かを判定する変更判定処理は車両制御に共通の処理であり、変更判定処理のアルゴリズムには高い信頼性を要求される。したがって、変更判定処理のライフサイクルは、照合情報のライフサイクルよりも長い。
【０１００】
（車上エネルギー管理手段１６０）
図８に示すように、車上エネルギー管理手段１６０は、車上エネルギーの管理処理として、グローバル生成１６２、グローバル供給１６４、グローバル保存１６６、グローバル消費１６８、グローバル回生１７０の各管理処理を実行する。車上エネルギーとしては、電力、熱等が考えられる。
【０１０１】
車上エネルギー管理手段１６０は、グローバル生成１６２およびグローバル保存１６６による車上エネルギーの生成量および保存量に基づいて、機能ドメインＥＣＵからのエネルギー消費要求をグローバル消費１６８として車両全体の観点から管理し、重要性および必要性に応じて消費量を調整する。そして、保存されている車上エネルギーを車両全体の観点からグローバル供給１６４として要求元に供給する。また、車上エネルギー管理手段１６０は、車両のトルク発生源の少なくとも一部としてモータを使用する車両において、バッテリの残容量、車両の走行状態等の車両全体の観点から、モータによる電気エネルギーのグローバル回生１７０を適切に管理する。
【０１０２】
また、車上エネルギーのグローバル生成１６２およびグローバル保存１６６の管理処理は、車上エネルギーの生成手段および保存手段の技術的な変化、ならびに車上エネルギーの生成および保存の時定数に基づいたグローバル生成１６２とグローバル保存１６６との最適な組み合わせにより、そのライフサイクルの長さが変化する。したがって、グローバル生成１６２およびグローバル保存１６６の管理処理のライフサイクルには、車上エネルギーを消費するグローバル消費１６８のライフサイクルとは異なる長さが設定される。
【０１０３】
（電子製品管理手段１８０）
図９に示すように、電子製品管理手段１８０は、グローバルＲＡＭ１８２、グローバルフラッシュメモリ１８４、グローバル演算装置１８６の配分、使用制限等を管理する。グローバルＲＡＭ１８２、グローバルフラッシュメモリ１８４、グローバル演算装置１８６は、例えば機能ドメインＥＣＵ２００、２０２、２０４、２０６が共有する電子製品資源である。
【０１０４】
近年、ＡＵＴＯＳＡＲ(Automotive Open System Architecture)等による車両における電子システムの標準化の推進により、ソフトウェアの変更が容易になっている。その結果、処理プログラムが必要とするメモリ容量、ＣＰＵへの処理負荷の割り当て等を、車両全体で管理することが望まれる。そして、このように、車両全体で電子製品の利用可能な資源を管理することにより、ソフトウェアの変更に対応するために電子製品資源を過剰に搭載することを防止し、電子製品の搭載量を必要な範囲で極力低減できる。これにより、ソフトウェアを変更するときに電子製品の利用可能な資源が不足するために電子製品を追加または変更せざるを得なくなる状況を、極力避けることができる。その結果、車両制御システム１０のライフサイクルを極力長くすることができる。
【０１０５】
（イントラボックス１００の構成例）
次に、イントラボックス１００の構成例について説明する。
（構成例１）
図１０に示すイントラボックス１００の構成例１は、イントラボックス１００の共通処理手段１２０を、非組み替え領域１２２と組み替え領域１２４とに分類している。非組み替え領域１２２と組み替え領域１２４とは、異なるマイコンにより実現されていることが望ましい。
【０１０６】
非組み替え領域１２２には、車両のライフサイクル以上のロングサイクルの共通処理として、例えば監査処理とバッテリの電力特性に基づく電力管理処理とを設けている。組み替え領域１２４には、車両のライフサイクルよりも短いショートライフサイクルの共通処理として、例えば情報管理のアクセス管理処理を設けている。このように、ロングサイクルとショートサイクルの共通処理を異なるマイコンで実現することにより、ショートサイクルの共通処理が組み替え領域１２４のマイコンで変更されても、ロングサイクルの共通処理が設けられている非組み替え領域１２２のマイコンは、ショートサイクルの共通処理の変更の影響を受けない。また、組み替え領域１２４のマイコンにとっても、変更の不要なロングサイクルの共通処理に関わらず、ショートサイクルの共通処理の変更が容易である。尚、組み替え領域１２４のマイコンにおいて、ショートサイクルの長さに基づいて、共通処理を分類し処理プログラムをモジュール化していることが望ましい。
【０１０７】
（構成例２）
図１１に示すイントラボックス１００の構成例２では、ロングサイクルの共通処理のうち、特に車両制御を正常に維持していくために冗長性が要求される重要処理を、複数のマイコンで実現している。例えば、監査処理は、制御対象の挙動が正常であるか異常であるかを判定し、異常の場合には制御対象に対する制御指令値の補正量を算出し、補正量に基づく挙動制御を制御処理手段に指令するので、一つのイントラボックス１００が故障しても、別のイントラボックスで監査処理を継続できることが望ましい。
【０１０８】
そこで、図１１に示す構成例２では、ロングサイクルの共通処理のうち、監査処理をイントラボックス１００とは異なる別のマイコン１２６にも設けて冗長系を構成している。これにより、イントラボックス１００またはマイコン１２６の一方が故障しても、イントラボックス１００またはマイコン１２６の他方により監査処理を継続できる。
【０１０９】
（オブジェクト化）
次に、制御処理手段および共通処理手段のオブジェクト化について説明する。図１２に示すように、共通処理手段は、ライフサイクルの異なる複数の共通処理手段２３０、２３２、２３４、２３６から構成されている。また、制御処理手段は、ライフサイクルの異なる複数の制御処理手段２４０、２４２、２４４、２４６から構成されている。
【０１１０】
共通処理手段２３２と共通処理手段２３４、共通処理手段２３６と制御処理手段２４０、制御処理手段２４２と制御処理手段２４４とは、車両制御においてそれぞれ同じライフサイクルの制御処理を実行しており、それぞれオブジェクト２５０、２５２、２５４を構成している。共通処理手段２３０と制御処理手段２４６とは、同じライフサイクルの制御処理を実行する処理手段が他になく、それぞれ単独でオブジェクト２５６、２５８を構成している。各オブジェクトは、ハードウェアとして他のオブジェクトと独立したマイコン（処理装置）で実現されていることが望ましい。
【０１１１】
このように、同じライフサイクルの制御処理を実行する処理手段をオブジェクト化することにより、ライフサイクルに応じて車両制御の変更がオブジェクト単位で容易になる。
（実行管理ルーチン１）
次に、イントラボックス１００の実行管理手段１１０が実行する車両制御の実行管理ルーチン１を図１３に示す。実行管理ルーチン１は常時実行される。Ｓ４００においてイントラボックス１００は、エンジンのスタートスイッチがオンされたか否かを判定する。
【０１１２】
スタートスイッチがオンされ車両制御が起動するとき（Ｓ４００：Ｙｅｓ）、Ｓ４０２においてイントラボックス１００は、共通処理および制御処理において、ライフサイクルの長い処理から順番に起動させる。例えば、バッテリの電気特性に基づいた電力管理の共通処理、駐車アシストの制御処理、情報管理の共通処理を順番に起動する。これにより、ライフサイクルの長い処理により実行環境が整えられた状態でライフサイクルの短い処理を実行できるので、起動時に、ライフサイクルの短い処理が誤った制御および診断を実行することを防止できる。
【０１１３】
Ｓ４０４においてイントラボックス１００は、パラメータ記憶手段１１２に記憶されている情報に基づいて、車両への搭載の終了タイミングに該当しライフサイクルが終了する制御処理が存在するか否かを判定する。ライフサイクルの終了する制御処理が存在しない場合（Ｓ４０４：Ｎｏ）、イントラボックス１００は本ルーチンを終了する。
【０１１４】
ライフサイクルの終了する制御処理が存在する場合（Ｓ４０４：Ｙｅｓ）、Ｓ４０６においてイントラボックス１００は、ディスプレイまたは警告灯によりライフサイクルの終了する制御処理を報知し、本ルーチンを終了する。
【０１１５】
スタートスイッチがオンされていない場合（Ｓ４００：Ｎｏ）、Ｓ４０８においてイントラボックス１００は、エンジンのスタートスイッチがオフされたか否かを判定する。スタートスイッチがオフされ車両制御を終了させるとき（Ｓ４０８：Ｙｅｓ）、Ｓ４１０においてイントラボックス１００は、共通処理および制御処理において、ライフサイクルの短い処理から順番に終了させる。例えば、車両情報管理の共通処理、駐車アシストの制御処理、バッテリの電気特性に基づいた電力管理の共通処理を順番に終了させる。これにより、ライフサイクルの長い処理により実行環境が整えられた状態でライフサイクルの短い処理を終了できるので、終了時に、ライフサイクルの短い処理が誤った制御および診断を実行することを防止できる。ライフサイクルの長い処理は、ライフサイクルの短い処理の実行が終了してから、記憶する必要のある情報をフラッシュメモリに書き込むなど、適切な終了処理を実行してから自身を終了する。
【０１１６】
（実行管理ルーチン２）
イントラボックス１００の実行管理手段１１０が実行する車両制御の実行管理ルーチン２を図１４に示す。実行管理ルーチン２は常時実行される。Ｓ４２０においてイントラボックス１００は、車両制御を実行する制御処理および共通処理のうち、リセットされる処理があるか否かを判定する。リセットされる処理がない場合（Ｓ４２０：Ｎｏ）、イントラボックス１００は本ルーチンを終了する。
【０１１７】
リセットされる処理がある場合（Ｓ４２０：Ｙｅｓ）、Ｓ４２２においてイントラボックス１００は、リセットされる処理のライフサイクルの長さ以上の処理はそのまま実行を継続させ、リセットされる処理よりもライフサイクルの短い処理の実行を停止させ待機させる。これにより、リセットされた処理よりもライフサイクルの短い処理が、リセットされた処理により実行環境が整えられていない状態で実行されることを防止できる。
【０１１８】
リセットされた処理が再開されると（Ｓ４２４：Ｙｅｓ）、Ｓ４２６においてイントラボックス１００は、リセットされた処理よりもライフサイクルの短い処理の実行を許可して本ルーチンを終了する。これにより、リセットされた処理により実行環境が整えられた状態で、リセットされた処理よりもライフサイクルの短い処理を実行できる。
【０１１９】
本実施形態では、図１３のＳ４００〜Ｓ４１０、および図１４のＳ４２０〜Ｓ４２６は、本発明の車両制御システムにおける実行管理手段としての機能に相当する。
［第２実施形態］
第２実施形態の車両制御システムを図１５に示す。
【０１２０】
車両制御システム６０においては、イントラボックス１００を設けず、パワートレインＥＣＵ７０、シャーシＥＣＵ３０、ボディＥＣＵ４０、インフォテインメントＥＣＵ５０の制御処理手段２２、３２、４２、５２において、制御対象に対する個々の制御処理に加え、車両制御に共通する共通処理をそれぞれ実行している。尚、パワートレインＥＣＵ７０、シャーシＥＣＵ３０、ボディＥＣＵ４０、およびインフォテインメントＥＣＵ５０の制御処理手段２２、３２、４２、５２が実行するライフサイクルの異なる処理の実行を管理するために、パワートレインＥＣＵ７０に実行管理手段７２およびパラメータ記憶手段７４を設けている。
【０１２１】
パワートレインＥＣＵ７０の実行管理手段７２は、車内ネットワーク３００により他の機能ドメインＥＣＵおよびサブドメインＥＣＵと通信しながら、ライフサイクルの異なる処理の実行を管理する。実行管理手段７２は、第１実施形態のイントラボックス１００に設けた実行管理手段１１０と実質的に同一の実行管理処理を実行する。
【０１２２】
また、パワートレインＥＣＵ７０は、パラメータ記憶手段７４に記憶されている情報に基づいて、車両への搭載の終了タイミングに該当しライフサイクルが終了する制御処理が存在するか否かを管理する。パラメータ記憶手段７４に記憶されている情報は、図２に示す情報と実質的に同じである。
【０１２３】
以上説明した上記実施形態では、車両制御の機能に応じて設定された制御処理のライフサイクルの長さに基づいて、車両における制御処理を分類している。これにより、ライフサイクルの長さに基づいて、車両制御処理を適切なタイミングで変更し、ライフサイクルが異なり変更不要な処理を変更することを防止できる。したがって、制御処理を適切に変更できる。
【０１２４】
また、ライフサイクルの長い処理は長く使用されるので、同じアルゴリズムが長く使用される。これにより、ライフサイクルの長い処理のアルゴリズムの問題点が解決される機会が増えるので、ライフサイクルの長い処理のアルゴリズムの信頼性が向上する。
【０１２５】
［他の実施形態］
上記実施形態では、イントラボックス１００または機能ドメインＥＣＵの一つとしてパワートレインＥＣＵ７０に実行管理手段を設けた。これ以外にも、実行管理手段はどの機能ドメインＥＣＵに設けてもよいし、あるいは実行管理手段だけを別のマイコンに設けてもよい。
【０１２６】
上記実施形態では、制御処理手段、実行管理手段、共通処理手段の機能を、処理プログラムにより機能が特定される車両制御システムにより実現している。これに対し、上記複数の手段の機能の少なくとも一部を、回路構成自体で機能が特定されるハードウェアで実現してもよい。
【０１２７】
このように、本発明は、上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々の実施形態に適用可能である。
【符号の説明】
【０１２８】
１０、６０：車両制御システム、２０、７０：パワートレインＥＣＵ、２２、３２、４２、５２：制御処理手段、２４、３４、４４、５４：サブドメインＥＣＵ、７２、１１０：実行管理手段、７４、１１２：パラメータ記憶手段、１００：イントラボックス（共通処理手段、実行管理手段）、１２０：共通処理手段、１３０：監査手段、１４０：情報管理手段、１５０：変更判定手段、１６０：車上エネルギー管理手段、１７０：電子製品管理手段、２００、２０２、２０４、２０６、２１０、２１２、２１４、２１６、２２０、２２２、２２４、２２６：機能ドメインＥＣＵ
【技術分野】
【０００１】
本発明は、車両に搭載された制御対象の挙動を制御する車両制御システムに関する。
【背景技術】
【０００２】
車両に搭載された制御対象の挙動を制御する車両制御を複数の制御処理に分類して実行する車両制御システムが知られている（例えば、特許文献１、２参照。）。分類された制御処理については、各マイクロコンピュータ（以下、マイコンとも言う。）が一つの制御処理を実行してもよいし、一つのマイコン内に設けた複数のプログラムモジュールがそれぞれ制御処理を実行することにより、一つのマイコンが複数の制御処理を実行してもよい。このように、車両制御を複数の制御処理に分類することにより、マイコン単位、またはマイコン内でのモジュール単位での変更が容易になる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−１０４１８９号公報
【特許文献２】特開２００１−２３９９０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、制御処理の分類の仕方によっては、一つの制御処理内に車両における存続期間であるライフサイクルの異なる処理が混在することがある。例えば、電源であるバッテリが鉛バッテリであるか、リチウムイオンバッテリであるかという、バッテリの発生電圧、充放電時間等の電気特性に基づく電力管理処理のライフサイクルは、車両のライフサイクルと同じか、またはそれ以上である。車両のライフサイクルとは、その車種の車両の製造が開始されてから終了するまでの期間を表している。したがって、バッテリ自体が製品寿命による劣化等により新しい同じバッテリに交換されても、バッテリの電気特性に基づく制御処理としての電力管理処理は、該当バッテリを搭載する車両が製造されている間は変更する必要がない。
【０００５】
一方、同じ電力管理処理において、車両に搭載されている個々の制御対象に電力を供給する電力供給に関する電力管理処理は、同じ車種であってもオプション製品の有無、モデルチェンジによる車載製品の変更等により、車両の製造期間中に変化する。つまり、電力管理において、バッテリの電気特性に基づく電力管理処理のライフサイクルの長さと、電力供給に関する電力管理処理のライフサイクルの長さとは異なっている。
【０００６】
このように、ライフサイクルの異なる制御処理を、単に電力管理として同じ制御処理に分類すると、オプション製品の追加、削除等により電力供給の電力管理処理を変更しなければならないときに、変更する必要のないバッテリの電気特性に基づく電力管理処理も変更されるという問題がある。
【０００７】
このように、変更する必要のないライフサイクルの長い制御処理をライフサイクルの短い制御処理と一緒に変更すると、ライフサイクルの長い制御処理のアルゴリズムが不必要に変更されることがある。その結果、同じアルゴリズムで制御処理を続ければアルゴリズムの問題点が解消される機会が増加するにも関わらず、その機会が低減するという問題が生じる。
【０００８】
本発明は、上記問題を解決するためになされたものであり、車両制御の機能に応じて設定されるライフサイクルに基づいて、車両制御を構成する制御処理を適切なタイミングで変更する車両制御システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
請求項１から１８に記載の発明によると、車両制御システムは、車両に搭載された複数の制御対象の挙動を制御するために複数の制御処理からなる車両制御を実行する制御処理手段と、車両制御のライフサイクルを車両制御の機能に応じて設定するパラメータを記憶しているパラメータ記憶手段と、を備え、制御処理は、パラメータにより設定されるライフサイクルの長さに基づいて分類されている。
【００１０】
これにより、パラメータ記憶手段に記憶されているパラメータにより設定された制御処理のライフサイクルの長さに基づいて、制御処理を適切なタイミングで変更できる。したがって、ライフサイクルが異なり変更不要な制御処理を変更することを防止できる。
【００１１】
このパラメータ記憶手段は、車両オンボード上で、パラメータによる分類がされれば、ライフサイクル毎の制御処理配置を後付の製品まで対象を拡大できるが、明らかにライフサイクルが定義される正規のオプション製品を含めた車両に標準装備される処理装置に限定すれば、車両オフボードで例えば設計段階もしくは車両ディーラでの限定的な取り扱いにおいて、ライフサイクル毎の制御処理配置集約を可能とする。
【００１２】
また、本発明ではパラメータをライフサイクル相違判断基準とした。パラメータとしては、ライフサイクルを判別するための手段、例えば処理装置における所定の電圧による記憶であったり、制御処理のプログラム実装領域であったり、制御処理のＡＰＩであったり等、何らかの判断が可能な手段であればよい。
【００１３】
また、パラメータは必ず一致しなくとも、ある範囲内、例えば車両のモデルチェンジよりは十分に長いものを一つのくくりにしてもよい。これにより不要に多くのライフサイクル分割を防止する。
【００１４】
また、ライフサイクルの長い制御処理は長く使用されるので、同じアルゴリズムが長く使用される。これにより、ライフサイクルの長い制御処理のアルゴリズムの問題点が解決される機会が増えるので、ライフサイクルの長い制御処理のアルゴリズムの信頼性が向上する。
【００１５】
ここで、ライフサイクルに応じて制御処理を変更する車両制御システムにおいて、制御処理を実行するハードウェアとしての処理装置を設ける場合、制御処理毎に処理装置が設けられてもよいし、複数の制御処理を同じライフサイクル毎に各処理装置に振り分けてもよいし、異なるライフサイクルの制御処理を同じ処理装置が実行してもよい。処理装置としては、例えばＣＰＵ、ＲＯＭ、ＲＡＭ等から構成されるマイコンが考えられる。
【００１６】
これにより、例えば車のモデルチェンジよりライフサイクルの長い制御処理が集約されていれば、このようなライフサイクルの長い制御処理を実行する処理装置が多種の車両モデルで共通利用できるので、車両メーカおよび部品メーカは自社の部品品番数を大幅に削減でき、１製品としての製品ライフサイクルを可能な限り延命することが可能になる。
【００１７】
さらに、近年車両使用年数が長期化する一方で、電子製品数の増加、ＣＰＵ等の電子部品の機能向上による部品ライフサイクルの短寿命化により電子製品の交換部品が入手困難のために車両修理が出来なくなる可能性を低減し、中古市場での部品調達が容易になる。これは引いては、車両廃棄の削減や中古電子処理装置の廃棄量を抑制する環境保護にも寄与する。
【００１８】
ここで、更にライフサイクルの長い制御処理がＣＰＵ等の電子部品の機能向上を考慮しアッパーコンパチで設計されれば、中古電子処理装置の再利用に留まらず、中古車両での新規処理装置による修理も可能になるので、リサイクル率の向上による環境保護にも寄与する。ここで言う環境保護は、廃棄物の処理だけの視点でなく、新たな物を余分に作り出さない意味でも考慮されるので、ＣＯ2削減効果にも寄与する。
【００１９】
これらの処理装置の再利用が向上する効果は、車両メーカや部品メーカの開発工数低減にも寄与する。まず単純に部品品番削減から開発する部品数が削減するだけでなく、通常車両毎に評価される評価を、イニシャルで切り替えた車両評価結果を部分的に継承できるので、開発期間の短縮にも寄与することになる。
【００２０】
また、異なるライフサイクルの制御処理を実行する処理プログラムを同じＲＯＭまたはフラッシュメッモリ等の記憶装置に記憶する場合、各処理プログラムをモジュール化し、異なる記憶領域に記憶する構成が考えられる。この場合、ライフサイクルに応じて、該当する記憶領域の処理プログラムだけを変更すればよい。
【００２１】
これにより、特に車両モデルチェンジと異なる長いライフサイクルと短いライフサイクルを混在させれば、ライフサイクルの相違による部品品番を増加させることなく、車両モデルチェンジに依存しない再利用可能な部品を全て集約可能になる。その結果、車両の部品構成において、購買者の嗜好に沿ったモデルチェンジ毎に変化するライフサイクル機能とは別に、購買者の嗜好とは関係ない機能集約が容易に進む。
【００２２】
即ち、車両の処理装置点数の増加は、言い換えれば購買者の嗜好変化に合わせて、従来提供された機能に対して車両機能が追加された、もしくは進化した結果であり、これに嗜好変化に影響しない機能が混在実装されることで、処理装置の再利用を阻んできた。
【００２３】
しかし、本発明により、購買者の嗜好を実現する機能と嗜好に関わらない機能とが分離可能となったため、従来は処理装置の再利用は嗜好変化を無視するしかなかったため、結局なかなか処理装置の再利用は進まず類似品が作られる結果に終わったが、初めて、本当に購買者の嗜好変化を局所化し、嗜好変化に応じつつも、単に１車両の処理装置点数だけでなく、車両メーカ全体の品番点数を押し下げる効果を発揮することができる。
【００２４】
また、プログラム開発環境として、例えばＭＡＴＬＡＢ（登録商標）等を使用して車両制御システムのモデルを設定する場合に、機能単位として異なるライフサイクルの制御処理のブロックを設定してプログラムコードを自動生成することも考えられる。ライフサイクルに応じて制御処理が変更になると、該当する制御処理のブロックは機能設定を変更し、変更されなかった制御処理のブロックは機能設定を変更しない。プログラムコードを自動生成する場合、ライフサイクルの異なる制御処理の処理プログラムがどのような記憶領域に配置されるかは、自動コード生成の仕様によるので予測できない。
【００２５】
請求項２に記載の発明によると、複数の制御対象は制御対象の機能に応じて分類された機能ドメインに統合されており、制御処理のライフサイクルの長さは機能ドメイン毎にパラメータにより設定されている。制御対象の機能とは、車両における制御対象の役割であり、例えばトルク発生系、制動系、娯楽情報系等に分類することができる。
【００２６】
機能ドメインは制御対象の機能に応じて複数の制御対象を分類して構成されているので、制御対象の機能に基づいて機能ドメイン毎に制御処理のライフサイクルが設定されることが望ましい。
【００２７】
請求項３に記載の発明によると、機能ドメインは制御対象の機能に応じて機能ドメインよりも詳細なサブドメインに分類されており、制御処理のライフサイクルの長さはサブドメイン毎にパラメータにより設定されている。
【００２８】
これにより、制御対象の機能に応じて機能ドメインよりも詳細に分類されたサブドメインに対し、詳細にライフサイクルを設定できる。
ところで、ユーザの嗜好、流行等に基づく車両に対するユーザのニーズは、制御対象である車載製品毎に異なる。例えば、バッテリの機能に対するユーザのニーズは低いので、バッテリに対する制御処理のライフサイクルは車両のライフサイクル以上であることが多い。これに対し、車両の安定走行の向上に対するユーザのニーズは高いので、車両のライフサイクル中であっても、ブレーキの制動力制御とインジェクタの噴射制御との連携制御を、１回または数回のモデルチェンジ毎に変更することがある。
【００２９】
そこで、請求項４に記載の発明によると、制御処理のライフサイクルの長さは、ユーザのニーズに基づいてパラメータにより設定されている。
これにより、ユーザのニーズが高い制御処理についてはライフサイクルを短くし、ニーズが低い制御処理についてはライフサイクルを長くすればよい。その結果、ユーザのニーズに応じてパラメータにより設定されたライフサイクル毎に、適切に制御処理を変更できる。
【００３０】
請求項５に記載の発明によると、車両制御に共通する少なくとも一つの共通処理を実行する共通処理手段をさらに備えている。そして、共通処理は、共通処理の機能に応じてパラメータにより設定された共通処理のライフサイクルの長さに基づいて分類されている。
【００３１】
制御対象に対する制御対象特有の車両制御とは異なり、車両制御に共通する少なくとも一つの共通処理を実行する共通処理手段を制御処理手段とは別に設けることにより、車両制御のうち共通処理と、それ以外の制御処理とを、それぞれの機能に応じたライフサイクルにより適切に分類できる。
【００３２】
また、車両制御に共通する共通処理は、車種に関わらずに共通な処理であることが多いので、異なる車種において同じ共通処理を使用できる。その結果、共通処理の再利用性が向上する。
【００３３】
請求項６に記載の発明によると、共通処理のライフサイクルの長さは、技術的なライフサイクルに基づいてパラメータにより設定されている。
ユーザの嗜好、流行等に基づく車両に対するユーザのニーズは、通常、制御対象の機能毎に異なっている。これに対し、車両制御に共通する共通処理は、ユーザのニーズとは異なり、技術的な観点からライフサイクルが設定されることが多い。したがって、車両制御に共通する共通処理のライフサイクルの長さを技術的なライフサイクルに基づいてパラメータが設定することにより、共通処理を、ユーザのニーズに関わらず技術的な観点により分類できる。
【００３４】
請求項７に記載の発明によると、複数の共通処理の一つは、制御対象の挙動が正常であるか異常であるかを判定し、異常である場合に制御処理手段による制御対象に対する制御指令値を補正する監査処理である。
【００３５】
制御対象の挙動が正常であるか異常であるかを判定し、挙動が異常の場合に制御対象に対する制御指令値を補正することにより制御対象の挙動を適切に制御する監査処理は、車両のモデルチェンジ等に関わらず、車両制御に共通の処理である。したがって、監査処理を共通処理の一つとすることにより、他の処理の変更による監査処理に対する影響を排除できる。
【００３６】
請求項８に記載の発明によると、複数の共通処理の一つは、車両情報の安全性を管理する情報管理処理である。
例えば、車両制御システムにおいて、メモリの不正な入れ替え等により処理プログラムが不正に改竄されていないか、処理プログラムがウィルスに感染していないか、車両所有者を認識するための個人情報の開示制限など、車両情報を管理する情報管理処理は、車両制御に共通の処理である。そして、このような情報管理処理は、技術的な進歩に応じて速やかに変更される必要がある。したがって、情報管理処理を共通処理の一つとすることにより、他の処理の変更による情報管理処理に対する影響を排除するとともに、情報管理処理を技術的な進歩に応じて速やかに変更できる。
【００３７】
請求項９に記載の発明によると、複数の共通処理の一つは、制御処理手段において変更可能なハードウェアまたはソフトウェアを特定する照合情報に基づいてハードウェアまたはソフトウェアの変更が適正であるか否かを判定する変更判定処理であり、変更判定処理のライフサイクルは照合情報のライフサイクルよりも長い。
【００３８】
ハードウェアまたはソフトウェアの変更が適正であるか否かの変更判定処理は、車両制御に共通の処理である。したがって、ハードウェアまたはソフトウェアの変更が適正であるか否かの判定処理を共通処理の一つとすることにより、他の処理の変更による変更判定処理に対する影響を排除できる。
【００３９】
尚、変更可能なハードウェアまたはソフトウェアを特定する照合情報としては、ハードウェアおよびソフトウェアのバージョン、製造会社等が考えられる。そして、照合情報は、新製品の開発等に応じて逐次更新される必要があるので、そのライフサイクルは短い。一方、照合情報に基づく変更可否の判定処理は信頼性を要求されるので、照合情報よりも長いライフサイクルが設定されている。
【００４０】
請求項１０に記載の発明によると、複数の共通処理の一つは、制御処理手段におけるハードウェアまたはソフトウェアの変更が適正である場合、制御処理手段が接続する通信系の通信設定を調整する通信設定処理である。
【００４１】
制御処理手段においてハードウェアまたはソフトウェアが適正に変更されると、制御処理手段が接続する通信系の通信設定を制御処理手段の変更に基づいて調整する必要がある。そして、通信設定を調整する通信設定処理は、車両制御に共通の処理である。したがって、通信設定処理を共通処理の一つとすることにより、他の処理の変更による通信設定処理に対する影響を排除できる。
【００４２】
ところで、電力および熱等の車両におけるエネルギーの生成、保存および消費等のエネルギー管理は、各エネルギーの時定数を考慮し、車両全体の観点から実行する必要がある。
【００４３】
そこで、請求項１１に記載の発明によると、複数の共通処理の一つは、車両におけるエネルギーを管理する車上エネルギー管理処理である。これにより、個々の制御対象に対する制御処理とは別に、エネルギー管理を車両全体の観点から実行できる。
【００４４】
請求項１２に記載の発明によると、複数の共通処理の一つは、制御処理手段に搭載された電子製品の余剰資源を管理する電子製品管理処理である。
これにより、オプション製品の追加、ソフトウェアまたはハードウェアのバージョンアップ等が実施される場合に、既存の搭載製品の余剰資源として、例えば、処理能力に余裕のあるＣＰＵに追加処理の一部を割り当てたり、未使用のメモリ領域を追加処理に割り当てることができる。その結果、新たな電子製品の追加を極力低減し、電子製品の資源の観点から車両制御システムのライフサイクルを極力延ばすことができる。
【００４５】
請求項１３に記載の発明によると、共通処理のライフサイクルは、車両のライフサイクル以上のロングサイクルと、車両のライフサイクルよりも短いショートサイクルとに分かれており、さらにショートサイクルの長さに基づいて共通処理が分類されている。
【００４６】
車両のライフサイクルよりも短いショートサイクルの共通処理は、車両のライフサイクル中に少なくとも１回変更される。したがって、ショートサイクルの長さに基づいて共通処理を分類することにより、ショートサイクルの共通処理において、不要な処理の変更を防止できる。
【００４７】
一方、車両のライフサイクル以上のロングサイクルの共通処理は、車両のライフサイクル中に変更する必要がなく、車両と同じライフサイクルと見なすことができる。したがって、車両のライフサイクル以上のロングサイクルの共通処理と、車両のライフサイクルよりも短いショートサイクルの共通処理とに分類することにより、ショートサイクルの共通処理の変更の影響を受けることなく、ロングサイクルの共通処理の信頼性を向上できる。
【００４８】
請求項１４に記載の発明によると、共通処理手段のうち、ロングサイクルの共通処理を実行する部分は、一つの処理装置に統合されている。
このように、ロングサイクルの共通処理を実行する共通処理手段の部分をショートサイクルの共通処理を実行する共通処理手段の部分から分離して一つの処理装置に統合することにより、ロングサイクルの共通処理を実行する共通処理手段の部分を統合した処理装置を全ての車両に共通して使用できる。その結果、処理装置のコストを低減できる。また、ショートサイクルの共通処理の変更が容易になる。
【００４９】
請求項１５に記載の発明によると、一つの処理装置に統合された共通処理手段のうち、冗長性が要求される部分をさらに別の処理装置に統合して冗長系を構成する。
これにより、ロングサイクルの共通処理を実行する共通処理手段の部分を統合した一つの処理装置が故障しても、別の処理装置により冗長性が要求される重要なロングサイクルの共通処理を実行できる。その結果、車両制御に必須の冗長性が要求されるバッテリ管理等のロングサイクルの共通処理が停止することを防止できる。
【００５０】
ところで、車両制御においてライフサイクルの長い処理は、エンジンを始動してから停止するまでの１トリップ中においても、実行を開始してから終了するまでの期間がライフサイクルの短い処理よりも長い。それは、通常、ライフサイクルの長い処理は、ライフサイクルの短い処理よりも処理範囲が広く、ライフサイクルの短い処理の実行環境を整備するからである。
【００５１】
例えば、電源管理処理は、電源管理処理よりもライフサイクルの短い他の制御処理よりも先に起動して電力供給を制御する必要があるし、他の制御処理が終了する前に電力供給制御を終了することはできない。したがって、ライフサイクルの長さに応じて処理の実行順序を適切に管理しないと、車両制御を正常に実行できないという問題が生じる。
【００５２】
そこで、請求項１６に記載の発明によると、車両制御の実行を管理する実行管理手段をさらに備え、実行管理手段は、ライフサイクルに基づいて車両制御を実行する処理の実行順序を管理し、車両制御の起動時には、ライフサイクルの長い処理をライフサイクルの短い処理よりも先に起動し、前記車両制御の終了時には、ライフサイクルの長い処理をライフサイクルの短い処理よりも後に終了させる。
【００５３】
これにより、車両制御の起動時には、ライフサイクルの長い処理により車両制御の実行環境が整備されてからライフサイクルの短い処理を実行できるので、ライフサイクルの長い処理により車両制御の実行環境が整備される前にライフサイクルの短い処理が誤った制御および診断を実行することを防止できる。
【００５４】
また、車両制御の終了時には、ライフサイクルの長い処理の終了により車両制御の実行環境が解消される前にライフサイクルの短い処理を終了できるので、車両制御の実行環境が解消された状態でライフサイクルの短い制御処理が誤った制御および診断を実行することを防止できる。一方、ライフサイクルの長い処理は、ライフサイクルの短い処理の実行が終了してから、記憶する必要のある情報をフラッシュメモリに書き込むなど、適切な終了処理を実行してから自身を終了する。
【００５５】
ところで、車両制御の実行中に、車両制御を実行する処理のうちいずれかの処理が異常発生等によりリセットされることがある。この場合、リセットされた処理よりもライフサイクルの長い処理は、リセットされた処理の実行環境に関わらずに正常に処理を継続できる。一方、リセットされた処理よりもライフサイクルの短い処理は、リセットされた処理の実行環境の元で実行されることが多いので、リセットされた処理の実行が再開されるまでの間は、正常に処理を実行できないことがある。
【００５６】
そこで、請求項１７に記載の発明によると、実行管理手段は、車両制御を実行する処理のうちいずれかの処理がリセットされると、リセットされた処理の実行が再開されるまで、リセットされた処理よりもライフサイクルの短い処理の実行を待機させる。
【００５７】
これにより、リセットされた処理の実行が再開され、リセットされた処理により整備された実行環境の元で、リセットされた処理よりもライフサイクルの短い処理を実行できる。
【００５８】
請求項１８に記載の発明によると、車両制御を実行する処理手段は同じライフサイクルの車両制御を実行する制御処理毎にオブジェクト化されている。これにより、ライフサイクルに応じて、車両制御の変更がオブジェクト単位で容易になる。
【００５９】
尚、本発明に備わる複数の手段の各機能は、構成自体で機能が特定されるハードウェア資源、プログラムにより機能が特定されるハードウェア資源、またはそれらの組み合わせにより実現される。また、これら複数の手段の各機能は、各々が物理的に互いに独立したハードウェア資源で実現されるものに限定されない。
【図面の簡単な説明】
【００６０】
【図１】第１実施形態の車両制御システムを示すブロック図。
【図２】パラメータ記憶手段に記憶されているパラメータを示す模式図。
【図３】ライフサイクルに応じて設定された車両制御の分類図。
【図４】共通処理の分類を示すブロック図。
【図５】共通処理のうち監査処理を示すブロック図。
【図６】共通処理のうち情報管理処理を示すブロック図。
【図７】共通処理のうち変更判定処理を示すブロック図。
【図８】共通処理のうち車上エネルギー管理処理を示すブロック図。
【図９】共通処理のうち電子製品管理処理を示すブロック図。
【図１０】イントラボックスの構成例を示すブロック図。
【図１１】イントラボックスの構成例を示すブロック図。
【図１２】オブジェクト化された処理手段を示すシステム図。
【図１３】実行管理ルーチン１を示すフローチャート。
【図１４】実行管理ルーチン２を示すフローチャート。
【図１５】第２実施形態の車両制御システムを示すブロック図。
【発明を実施するための形態】
【００６１】
以下、本発明の実施の形態を図に基づいて説明する。
［第１実施形態］
本発明の第１実施形態による車両制御システムを図１に示す。
【００６２】
（車両制御システム１０）
車両制御システム１０は、パワートレイン(Power Train)ＥＣＵ(Electronic Control Unit)２０、シャーシ(Chassis)ＥＣＵ３０、ボディ(Body)ＥＣＵ４０、インフォテインメント(Infotainment)ＥＣＵ５０、イントラボックス(Intra Box)１００等から構成されている。パワートレインＥＣＵ２０、シャーシＥＣＵ３０、ボディＥＣＵ４０、インフォテインメントＥＣＵ５０は、それぞれ車両に搭載されている制御対象の機能、言い換えれば車両における制御対象の役割に応じて分類された機能ドメインであるパワートレインドメイン、シャーシドメイン、ボディドメイン、インフォテインメントドメイン毎に、制御対象の挙動を制御するための制御処理を機能ドメイン単位で実行する機能ドメインＥＣＵである。各機能ドメインＥＣＵには、制御対象の挙動を制御する複数の制御処理を実行する制御処理手段２２、３２、４２、５２が設けられている。
【００６３】
各機能ドメインは、制御対象の機能に応じて機能ドメインよりも詳細なサブドメインに分類されている。そして、これらサブドメイン毎に制御対象の挙動を制御するサブドメインＥＣＵ２４、３４、４４、５４が各機能ドメインＥＣＵに接続している。
【００６４】
パワートレインＥＣＵ２０とシャーシＥＣＵ３０とボディＥＣＵ４０とインフォテインメントＥＣＵ５０とイントラボックス１００とは、例えばＦｌｅｘＲａｙ（Daimler Chrysler社の登録商標）による車内ネットワーク３００により互いに通信可能に接続されており、各機能ドメインＥＣＵとそのサブドメインＥＣＵとはＣＡＮ（Controller Area Network）、ＭＯＳＴ(Media Oriented Systems Transport)等による車内ネットワーク３１０により互いに通信可能に接続されている。車内ネットワーク３００と車内ネットワーク３１０とは、同じ形式のネットワークでもよい。
【００６５】
尚、機能ドメインの分類は上記に限るものではなく、機能ドメインに含まれる制御対象も種々の組み合わせが考えられる。また、すべての制御対象を機能ドメインに分類する必要はなく、一部の制御対象だけを機能ドメインに統合してもよい。また、機能ドメインが複数のサブドメインに分類されておらず、機能ドメインＥＣＵが機能ドメイン内のすべての制御対象の挙動を制御してもよい。
【００６６】
（制御処理手段）
パワートレインＥＣＵ２０の制御処理手段２２は、制御対象であるインジェクタ、変速機等の挙動をパワートレインドメイン単位で統合して制御する。
【００６７】
シャーシＥＣＵ３０の制御処理手段３２は、制御対象であるステアリング、ブレーキ等の挙動をシャーシドメイン単位で統合して制御する。
ボディＥＣＵ４０の制御処理手段４２は、制御対象である空調、ドア等の挙動をボディドメイン単位で統合して制御する。
【００６８】
インフォテインメントＥＣＵ５０の制御処理手段５２は、制御対象であるオーディオ装置、ナビゲーション装置等の挙動をインフォテインメントドメイン単位で統合して制御する。
【００６９】
サブドメインＥＣＵ２４、３４、４４、５４には、各機能ドメインを構成するサブドメインの制御対象の挙動を、例えば高圧ポンプの吐出量、左前輪ブレーキ、ステアリング、右前ドア、ＣＤプレイヤー毎に個別に制御する図示しない制御処理手段が設けられている。
【００７０】
各機能ドメインＥＣＵおよびサブドメインＥＣＵは、図示しないＣＰＵ、ＲＯＭ、ＲＡＭ、およびフラッシュメモリ等からなるマイコンにより主に構成されている。
機能ドメインＥＣＵおよびサブドメインＥＣＵに設けられた制御処理手段は、機能ドメイン毎に制御対象に対して複数の制御処理を実行する。そして、これら複数の制御処理は、車両制御の機能に応じて分類された制御処理のライフサイクルの長さに基づいて設定されている。そして、個々の機能ドメインに対する車両制御に応じて大まかなライフサイクルの範囲が設定されており、さらに機能ドメインを構成するサブドメインに対する車両制御に応じて詳細なライフサイクルが設定されている。尚、同じライフサイクルであれば、同じ機能ドメインの異なるサブドメインであっても、例えば、ブレーキ制御処理とステアリング制御処理とを同じ制御処理にしてもよい。
【００７１】
イントラボックス１００は、実行管理手段１１０、パラメータ記憶手段１１２、および共通処理手段１２０等から構成されている。実行管理手段１１０、パラメータ記憶手段１１２および共通処理手段１２０は、図示しないＣＰＵ、ＲＯＭ、ＲＡＭ、およびフラッシュメモリ等からなるマイコンにより主に構成されている。本実施形態では、イントラボックス１００を構成する処理装置としてのマイコンは、機能ドメインＥＣＵ、サブドメインＥＣＵとは異なる独立したマイコンである。
【００７２】
（実行管理手段１１０）
イントラボックス１００の実行管理手段１１０は、エンジンの始動、停止に伴う車両制御の起動時および終了時において、機能ドメインＥＣＵおよびサブＥＣＵの制御処理手段が実行する複数の制御処理、ならびにイントラボックス１００の共通処理手段１２０が実行する複数の共通処理の実行順序を、車両全体の観点から管理する。イントラボックス１００の共通処理手段１２０が実行する共通処理の詳細については後述する。
【００７３】
実行管理手段１１０は、車両制御の起動時には、制御処理および共通処理通のうち、ライフサイクルの長い処理をライフサイクルの短い処理よりも先に起動する。ライフサイクルの長い処理は、車両制御の実行環境を整える処理が多いので、ライフサイクルの長い処理を起動し、車両制御の実行環境を整えてからライフサイクルの短い処理を起動する。これにより、車両制御の実行環境が整えられてからライフサイクルの短い処理を起動できる。
【００７４】
実行管理手段１１０は、車両制御の終了時には、制御処理および共通処理通のうち、ライフサイクルの長い処理をライフサイクルの短い処理よりも後に終了させる。これにより、車両制御の実行環境が整えられた状態でライフサイクルの短い処理を終了させることができる。
【００７５】
ここで、エンジン停止後の蒸発燃料のリークチェックのように、エンジンのスタートスイッチがオフされてから所定時間経過後にソークタイマによりＥＣＵを起動することがある。このように、スタートスイッチオフ後において起動される車両制御においても、ライフサイクルの長い制御処理を起動して車両制御の実行環境を整えてから、ライフサイクルの短い処理を起動する。
【００７６】
例えば、エンジン停止後の蒸発燃料のリークチェックのために電磁弁を駆動する場合、バッテリの充電残量をチェックする処理により電磁弁の駆動が可能と判断されてから、リークチェック処理が起動され、電磁弁に電力が供給される。この場合、バッテリの充電残量管理処理のライフサイクルが一番長く、リークチェック処理、電磁弁への電力供給処理の順にライフサイクルが短くなる。
【００７７】
また、実行管理手段１１０は、車両制御中に、制御処理および共通処理のうちいずれかの処理に異常等が発生しリセットされると、リセットされた処理よりもライフサイクルの短い処理の実行を一旦停止させ待機させる。これは、リセットされた処理よりもライフサイクルの短い処理は、リセットされた処理の実行環境の元で実行されることがあるので、リセットされた処理の実行が再開されるまでの間は、正常に処理を実行できないことがあるからである。これに対し、リセットされた処理よりもライフサイクルの長い処理は、リセットされた処理の実行環境に関わらずに正常に処理を継続できる。
【００７８】
そして、実行管理手段１１０は、リセットされた処理の実行が再開されると、リセットされた処理よりもライフサイクルの短い処理の実行を許可する。これにより、リセットされた処理が再開され実行環境が整えられた状態で、リセットされた処理よりもライフサイクルの短い処理を実行できる。
【００７９】
（パラメータ記憶手段１１２）
図２に示すように、パラメータ記憶手段１１２は、例えば書き換え可能なメモリ装置としてフラッシュメモリにより構成されている。図２に示すように、パラメータ記憶手段１１２には、車両制御を構成する複数の制御処理と、各制御処理が車両に搭載された搭載開始時期と、車両に搭載可能な期間と、使用可能回数とが記憶されている。制御処理のライフサイクルとして、制御処理の機能に応じて、搭載開始時期と搭載可能期間、ならびに使用可能回数の少なくともいずれか一方がパラメータとして設定されている。搭載開始時期と搭載可能期間または使用可能回数の一方だけを設定する場合は、設定されないパラメータの欄には、初期値として例えば０が設定される。
【００８０】
搭載開始時期と搭載可能期間とにより、対象となる制御処理の搭載期間が終了し制御処理を変更するタイミングを知ることができる。また、使用可能回数は、制御処理の起動から終了を１回とし、初期に設定した使用可能回数から使用毎にカウントダウンすることにより、制御処理の変更時期を知ることができる。
【００８１】
尚、制御処理を車両に搭載可能な期間とは、制御処理が挙動を制御する制御対象が異なる機能の制御対象に変更されるまでの期間を表している。例えば、後述する駐車アシスト処理であれば、駐車時に障害物を車載カメラで検知して報知するだけであったものが、モデルチェンジにより、ステアリングおよびブレーキの自動操作によるアシスト処理に変更されることがある。この場合、モデルチェンジまでの期間が搭載可能期間となる。
【００８２】
また、使用可能回数としては、例えばダウンロードした車両用のウィルスチェックプログラムの無料使用回数が１０回であれば、初回の使用可能回数として１０回が設定される。そして１０回使用すると、使用を停止するか、料金を支払って正規版を購入する必要がある。
【００８３】
ライフサイクルを設定するパラメータとして、上記以外にも、法規の切り替わり時期、最新バージョン、車両ソフトを管理するプラットホームの大幅な変更時期等を採用してもよい。
【００８４】
ライフサイクルを設定するパラメータは、例えば、ディーラ等において外部端末を接続するか、管理センターとの通信により最新情報に更新することができる。
（ライフサイクルに基づく制御処理の分類）
次に、車両制御の機能に応じて設定されたライフサイクルに基づく、制御処理の分類について説明する。
【００８５】
図３に示すように、パワートレインＥＣＵ２０、シャーシＥＣＵ３０、ボディＥＣＵ４０、インフォテインメントＥＣＵ５０に相当する機能ドメインＥＣＵ２００、２０２、２０４、２０６（図４参照）、サブドメインＥＣＵ、イントラボックス１００が実行する制御処理は、ライフサイクルの長さに応じて設定されている。図３では、サブドメインＥＣＵを省略している。また、図３の△は、車両のモデルチェンジのタイミングを示している。
【００８６】
例えば、前述した鉛バッテリであるか、リチウムイオンバッテリであるかという、バッテリの発生電圧、充放電時間等の電気特性に基づく電力管理処理のライフサイクルは、車両のライフサイクル以上である。したがって、バッテリの電気特性に基づく電力管理処理は、モデルチェンジがあっても変更されず、該当車両が製造されている間は同じ処理が実行される。
【００８７】
これに対し、車両を駐車するときのアシスト処理は、１回または数回のモデルチェンジ毎に変更されることがある。例えば、車両の発売当初は、駐車時に単に障害物を車載カメラで検知し、警報や音声で報知するだけであったものが、モデルチェンジにより、ステアリングおよびブレーキの自動操作によるアシスト処理に変更されることがある。したがって、駐車アシスト処理のライフサイクルは、バッテリの電気特性に基づく電力管理処理よりも短い。
【００８８】
駐車アシスト処理と同じく、１回または数回のモデルチェンジ毎に変更される処理として、車両の安定走行制御処理が考えられる。発売当初においては、ＡＢＳ(Anti-lock Brake System)によりブレーキのロック状態を回避してブレーキの制動力を確保するだけであったものが、モデルチェンジによりブレーキの制動力制御にインジェクタの噴射制御を加えたＥＳＰ(Electronic Stability Program)に変更されることがある。このように、ＡＢＳからＥＳＰに変更することにより、スピン等により車両コントロールが不安定になった状態でも、ブレーキ制御と噴射制御等をＥＣＵで実行し、車両コントロールが不安定な状態になることを回避できる。
【００８９】
駐車アシスト処理および車両の安定走行制御処理等は、ユーザの嗜好および流行等によりユーザのニーズが高い処理であるから、技術的な観点とは別に、ユーザのニーズに応じてライフサイクルが設定されることがある。
【００９０】
また、情報管理処理においては、車両情報へのアクセス管理処理のように、ウィルス検出プログラムの更新を随時実施するものがある。したがって、アクセス管理処理のライフサイクルは、駐車アシスト処理およびブレーキ制御処理のライフサイクルよりも短い。
【００９１】
（共通処理手段１２０）
図１に示すイントラボックス１００の共通処理手段１２０は、機能ドメインＥＣＵおよびサブドメインＥＣＵの制御処理手段が機能ドメイン単位およびサブドメイン単位で制御対象に対して実行する車両制御に共通する複数の共通処理を実行する。
【００９２】
図４に示すように、イントラボックス１００の共通処理手段１２０は、複数の共通処理として、監査処理を実行する監査手段１３０、情報管理処理を実行する情報管理手段１４０、変更判定処理を実行する変更判定手段１５０、車上エネルギー管理処理を実行する車上エネルギー管理手段１６０、電子製品の余剰資源を管理する電子製品管理手段１８０を有している。このような、車両制御に共通する共通処理は、通常、車種に関わらずに共通な処理であるため、異なる車種において同じ共通処理を使用できる。
【００９３】
（監査手段１３０）
図５に示すように、監査手段１３０は、機能ドメインＥＣＵ２００、２０２、２０４、２０６の挙動制御の異常を監査することにより、車両制御システム１０の観点から車両のグローバル挙動１３２の異常を判定し、グローバル診断１３４により異常原因を診断する。
【００９４】
グローバル挙動１３２は、機能ドメインＥＣＵ２００、２０２、２０４、２０６のうち複数の機能ドメインＥＣＵによる挙動制御の結果として生じる車両の挙動である。例えば、各タイヤに対するブレーキ制御およびインジェクタに対する噴射制御の結果として生じる車両の横ずれ、スピンがグローバル挙動１３２である。また、グローバル診断１３４は、グローバル挙動１３２の異常原因を、複数の機能ドメインＥＣＵによる挙動制御に基づいて診断する。例えば、各タイヤに対するブレーキ制御およびインジェクタに対する噴射制御が正常であっても、結果として車両がスピンする場合には、グローバル診断１３４はグローバル挙動１３２の異常と判定し、グローバル挙動１３２が正常になるようにブレーキおよびインジェクタに対する制御指令値の補正量を算出し、シャーシＥＣＵ３０およびパワートレインＥＣＵ２０に補正量に基づく制御を指令する。
【００９５】
このように、監査処理は、車両制御に共通する処理であり、高い信頼性を要求される監査処理の基本的な処理機能のライフサイクルの長さは車両のライフサイクル以上である。
（情報管理手段１４０）
図６に示すように、情報管理手段１４０は、個々の機能ドメインＥＣＵ２００、２０２、２０４、２０６において、または機能ドメインＥＣＵ間において、車両情報が適正に処理されているかを管理する。例えば、情報管理手段１４０は、メモリの不正な入れ替え等により処理プログラムが不正に改竄され、その結果として不正な情報が車内ＬＡＮにおいて送受信されていないかをチェックする不正改竄チェック１４２、あるいは、処理プログラムがウィルスに感染している結果、メモリの書き込み禁止領域に書き込み要求が実行されたかをチェックする不正アクセスチェック１４４を実行する。これ以外にも、情報管理手段１４０は、車両所有者を認識するための個人情報の開示制限などを実行する。
【００９６】
情報管理処理は車両制御に共通の処理であり、技術的な進歩が著しい分野である。したがって、情報管理処理は、技術的な進歩に応じて短いライフサイクルで速やかに変更される必要がある。そこで、情報管理処理を共通処理の一つとすることにより、他の処理の変更による情報管理処理に対する影響を排除するとともに、情報管理処理を技術的な進歩に応じて速やかに変更できる。
【００９７】
（変更判定手段１５０）
図７に示すように、変更判定手段１５０は、車両制御システム１０のシステム構成を管理する。図７において、符号２１０、２１２、２１４、２１６、２２０、２２２、２２４、２２６は、例えば機能ドメインＥＣＵを表している。
【００９８】
変更判定手段１５０は、機能ドメインＥＣＵ２１０、２１２の供給元１、２の違い、機能ドメインＥＣＵ２１４、２１６のオプション搭載の有無、機能ドメインＥＣＵ２２０の後付搭載、機能ドメインＥＣＵ２２２のうち一部のソフトウェア（ＳＷ）のＶ（バージョン）１．０からＶ１．１へのアップデート、不具合等によるＶ２．０の機能ドメインＥＣＵ２２４からＶ３．０の機能ドメインＥＣＵ２２６への製品の交換等を検出する。そして、変更判定手段１５０は、検出したシステム構成に応じて、各機能ドメインＥＣＵにおいて変更可能なハードウェアおよびソフトウェアの製品を特定する照合情報を記憶している。そして、照合情報に基づいて、変更のあった製品が適切に変更された製品であるか否かを判定する。適切に変更された場合、変更判定手段１５０は、変更された製品が接続する通信系の通信設定を調整する通信設定手段としても機能する。
【００９９】
変更可能なハードウェアおよびソフトウェアの製品を特定する照合情報は、常に新しい情報に変更される必要がある。一方、照合情報に基づいて変更が適正であるか否かを判定する変更判定処理は車両制御に共通の処理であり、変更判定処理のアルゴリズムには高い信頼性を要求される。したがって、変更判定処理のライフサイクルは、照合情報のライフサイクルよりも長い。
【０１００】
（車上エネルギー管理手段１６０）
図８に示すように、車上エネルギー管理手段１６０は、車上エネルギーの管理処理として、グローバル生成１６２、グローバル供給１６４、グローバル保存１６６、グローバル消費１６８、グローバル回生１７０の各管理処理を実行する。車上エネルギーとしては、電力、熱等が考えられる。
【０１０１】
車上エネルギー管理手段１６０は、グローバル生成１６２およびグローバル保存１６６による車上エネルギーの生成量および保存量に基づいて、機能ドメインＥＣＵからのエネルギー消費要求をグローバル消費１６８として車両全体の観点から管理し、重要性および必要性に応じて消費量を調整する。そして、保存されている車上エネルギーを車両全体の観点からグローバル供給１６４として要求元に供給する。また、車上エネルギー管理手段１６０は、車両のトルク発生源の少なくとも一部としてモータを使用する車両において、バッテリの残容量、車両の走行状態等の車両全体の観点から、モータによる電気エネルギーのグローバル回生１７０を適切に管理する。
【０１０２】
また、車上エネルギーのグローバル生成１６２およびグローバル保存１６６の管理処理は、車上エネルギーの生成手段および保存手段の技術的な変化、ならびに車上エネルギーの生成および保存の時定数に基づいたグローバル生成１６２とグローバル保存１６６との最適な組み合わせにより、そのライフサイクルの長さが変化する。したがって、グローバル生成１６２およびグローバル保存１６６の管理処理のライフサイクルには、車上エネルギーを消費するグローバル消費１６８のライフサイクルとは異なる長さが設定される。
【０１０３】
（電子製品管理手段１８０）
図９に示すように、電子製品管理手段１８０は、グローバルＲＡＭ１８２、グローバルフラッシュメモリ１８４、グローバル演算装置１８６の配分、使用制限等を管理する。グローバルＲＡＭ１８２、グローバルフラッシュメモリ１８４、グローバル演算装置１８６は、例えば機能ドメインＥＣＵ２００、２０２、２０４、２０６が共有する電子製品資源である。
【０１０４】
近年、ＡＵＴＯＳＡＲ(Automotive Open System Architecture)等による車両における電子システムの標準化の推進により、ソフトウェアの変更が容易になっている。その結果、処理プログラムが必要とするメモリ容量、ＣＰＵへの処理負荷の割り当て等を、車両全体で管理することが望まれる。そして、このように、車両全体で電子製品の利用可能な資源を管理することにより、ソフトウェアの変更に対応するために電子製品資源を過剰に搭載することを防止し、電子製品の搭載量を必要な範囲で極力低減できる。これにより、ソフトウェアを変更するときに電子製品の利用可能な資源が不足するために電子製品を追加または変更せざるを得なくなる状況を、極力避けることができる。その結果、車両制御システム１０のライフサイクルを極力長くすることができる。
【０１０５】
（イントラボックス１００の構成例）
次に、イントラボックス１００の構成例について説明する。
（構成例１）
図１０に示すイントラボックス１００の構成例１は、イントラボックス１００の共通処理手段１２０を、非組み替え領域１２２と組み替え領域１２４とに分類している。非組み替え領域１２２と組み替え領域１２４とは、異なるマイコンにより実現されていることが望ましい。
【０１０６】
非組み替え領域１２２には、車両のライフサイクル以上のロングサイクルの共通処理として、例えば監査処理とバッテリの電力特性に基づく電力管理処理とを設けている。組み替え領域１２４には、車両のライフサイクルよりも短いショートライフサイクルの共通処理として、例えば情報管理のアクセス管理処理を設けている。このように、ロングサイクルとショートサイクルの共通処理を異なるマイコンで実現することにより、ショートサイクルの共通処理が組み替え領域１２４のマイコンで変更されても、ロングサイクルの共通処理が設けられている非組み替え領域１２２のマイコンは、ショートサイクルの共通処理の変更の影響を受けない。また、組み替え領域１２４のマイコンにとっても、変更の不要なロングサイクルの共通処理に関わらず、ショートサイクルの共通処理の変更が容易である。尚、組み替え領域１２４のマイコンにおいて、ショートサイクルの長さに基づいて、共通処理を分類し処理プログラムをモジュール化していることが望ましい。
【０１０７】
（構成例２）
図１１に示すイントラボックス１００の構成例２では、ロングサイクルの共通処理のうち、特に車両制御を正常に維持していくために冗長性が要求される重要処理を、複数のマイコンで実現している。例えば、監査処理は、制御対象の挙動が正常であるか異常であるかを判定し、異常の場合には制御対象に対する制御指令値の補正量を算出し、補正量に基づく挙動制御を制御処理手段に指令するので、一つのイントラボックス１００が故障しても、別のイントラボックスで監査処理を継続できることが望ましい。
【０１０８】
そこで、図１１に示す構成例２では、ロングサイクルの共通処理のうち、監査処理をイントラボックス１００とは異なる別のマイコン１２６にも設けて冗長系を構成している。これにより、イントラボックス１００またはマイコン１２６の一方が故障しても、イントラボックス１００またはマイコン１２６の他方により監査処理を継続できる。
【０１０９】
（オブジェクト化）
次に、制御処理手段および共通処理手段のオブジェクト化について説明する。図１２に示すように、共通処理手段は、ライフサイクルの異なる複数の共通処理手段２３０、２３２、２３４、２３６から構成されている。また、制御処理手段は、ライフサイクルの異なる複数の制御処理手段２４０、２４２、２４４、２４６から構成されている。
【０１１０】
共通処理手段２３２と共通処理手段２３４、共通処理手段２３６と制御処理手段２４０、制御処理手段２４２と制御処理手段２４４とは、車両制御においてそれぞれ同じライフサイクルの制御処理を実行しており、それぞれオブジェクト２５０、２５２、２５４を構成している。共通処理手段２３０と制御処理手段２４６とは、同じライフサイクルの制御処理を実行する処理手段が他になく、それぞれ単独でオブジェクト２５６、２５８を構成している。各オブジェクトは、ハードウェアとして他のオブジェクトと独立したマイコン（処理装置）で実現されていることが望ましい。
【０１１１】
このように、同じライフサイクルの制御処理を実行する処理手段をオブジェクト化することにより、ライフサイクルに応じて車両制御の変更がオブジェクト単位で容易になる。
（実行管理ルーチン１）
次に、イントラボックス１００の実行管理手段１１０が実行する車両制御の実行管理ルーチン１を図１３に示す。実行管理ルーチン１は常時実行される。Ｓ４００においてイントラボックス１００は、エンジンのスタートスイッチがオンされたか否かを判定する。
【０１１２】
スタートスイッチがオンされ車両制御が起動するとき（Ｓ４００：Ｙｅｓ）、Ｓ４０２においてイントラボックス１００は、共通処理および制御処理において、ライフサイクルの長い処理から順番に起動させる。例えば、バッテリの電気特性に基づいた電力管理の共通処理、駐車アシストの制御処理、情報管理の共通処理を順番に起動する。これにより、ライフサイクルの長い処理により実行環境が整えられた状態でライフサイクルの短い処理を実行できるので、起動時に、ライフサイクルの短い処理が誤った制御および診断を実行することを防止できる。
【０１１３】
Ｓ４０４においてイントラボックス１００は、パラメータ記憶手段１１２に記憶されている情報に基づいて、車両への搭載の終了タイミングに該当しライフサイクルが終了する制御処理が存在するか否かを判定する。ライフサイクルの終了する制御処理が存在しない場合（Ｓ４０４：Ｎｏ）、イントラボックス１００は本ルーチンを終了する。
【０１１４】
ライフサイクルの終了する制御処理が存在する場合（Ｓ４０４：Ｙｅｓ）、Ｓ４０６においてイントラボックス１００は、ディスプレイまたは警告灯によりライフサイクルの終了する制御処理を報知し、本ルーチンを終了する。
【０１１５】
スタートスイッチがオンされていない場合（Ｓ４００：Ｎｏ）、Ｓ４０８においてイントラボックス１００は、エンジンのスタートスイッチがオフされたか否かを判定する。スタートスイッチがオフされ車両制御を終了させるとき（Ｓ４０８：Ｙｅｓ）、Ｓ４１０においてイントラボックス１００は、共通処理および制御処理において、ライフサイクルの短い処理から順番に終了させる。例えば、車両情報管理の共通処理、駐車アシストの制御処理、バッテリの電気特性に基づいた電力管理の共通処理を順番に終了させる。これにより、ライフサイクルの長い処理により実行環境が整えられた状態でライフサイクルの短い処理を終了できるので、終了時に、ライフサイクルの短い処理が誤った制御および診断を実行することを防止できる。ライフサイクルの長い処理は、ライフサイクルの短い処理の実行が終了してから、記憶する必要のある情報をフラッシュメモリに書き込むなど、適切な終了処理を実行してから自身を終了する。
【０１１６】
（実行管理ルーチン２）
イントラボックス１００の実行管理手段１１０が実行する車両制御の実行管理ルーチン２を図１４に示す。実行管理ルーチン２は常時実行される。Ｓ４２０においてイントラボックス１００は、車両制御を実行する制御処理および共通処理のうち、リセットされる処理があるか否かを判定する。リセットされる処理がない場合（Ｓ４２０：Ｎｏ）、イントラボックス１００は本ルーチンを終了する。
【０１１７】
リセットされる処理がある場合（Ｓ４２０：Ｙｅｓ）、Ｓ４２２においてイントラボックス１００は、リセットされる処理のライフサイクルの長さ以上の処理はそのまま実行を継続させ、リセットされる処理よりもライフサイクルの短い処理の実行を停止させ待機させる。これにより、リセットされた処理よりもライフサイクルの短い処理が、リセットされた処理により実行環境が整えられていない状態で実行されることを防止できる。
【０１１８】
リセットされた処理が再開されると（Ｓ４２４：Ｙｅｓ）、Ｓ４２６においてイントラボックス１００は、リセットされた処理よりもライフサイクルの短い処理の実行を許可して本ルーチンを終了する。これにより、リセットされた処理により実行環境が整えられた状態で、リセットされた処理よりもライフサイクルの短い処理を実行できる。
【０１１９】
本実施形態では、図１３のＳ４００〜Ｓ４１０、および図１４のＳ４２０〜Ｓ４２６は、本発明の車両制御システムにおける実行管理手段としての機能に相当する。
［第２実施形態］
第２実施形態の車両制御システムを図１５に示す。
【０１２０】
車両制御システム６０においては、イントラボックス１００を設けず、パワートレインＥＣＵ７０、シャーシＥＣＵ３０、ボディＥＣＵ４０、インフォテインメントＥＣＵ５０の制御処理手段２２、３２、４２、５２において、制御対象に対する個々の制御処理に加え、車両制御に共通する共通処理をそれぞれ実行している。尚、パワートレインＥＣＵ７０、シャーシＥＣＵ３０、ボディＥＣＵ４０、およびインフォテインメントＥＣＵ５０の制御処理手段２２、３２、４２、５２が実行するライフサイクルの異なる処理の実行を管理するために、パワートレインＥＣＵ７０に実行管理手段７２およびパラメータ記憶手段７４を設けている。
【０１２１】
パワートレインＥＣＵ７０の実行管理手段７２は、車内ネットワーク３００により他の機能ドメインＥＣＵおよびサブドメインＥＣＵと通信しながら、ライフサイクルの異なる処理の実行を管理する。実行管理手段７２は、第１実施形態のイントラボックス１００に設けた実行管理手段１１０と実質的に同一の実行管理処理を実行する。
【０１２２】
また、パワートレインＥＣＵ７０は、パラメータ記憶手段７４に記憶されている情報に基づいて、車両への搭載の終了タイミングに該当しライフサイクルが終了する制御処理が存在するか否かを管理する。パラメータ記憶手段７４に記憶されている情報は、図２に示す情報と実質的に同じである。
【０１２３】
以上説明した上記実施形態では、車両制御の機能に応じて設定された制御処理のライフサイクルの長さに基づいて、車両における制御処理を分類している。これにより、ライフサイクルの長さに基づいて、車両制御処理を適切なタイミングで変更し、ライフサイクルが異なり変更不要な処理を変更することを防止できる。したがって、制御処理を適切に変更できる。
【０１２４】
また、ライフサイクルの長い処理は長く使用されるので、同じアルゴリズムが長く使用される。これにより、ライフサイクルの長い処理のアルゴリズムの問題点が解決される機会が増えるので、ライフサイクルの長い処理のアルゴリズムの信頼性が向上する。
【０１２５】
［他の実施形態］
上記実施形態では、イントラボックス１００または機能ドメインＥＣＵの一つとしてパワートレインＥＣＵ７０に実行管理手段を設けた。これ以外にも、実行管理手段はどの機能ドメインＥＣＵに設けてもよいし、あるいは実行管理手段だけを別のマイコンに設けてもよい。
【０１２６】
上記実施形態では、制御処理手段、実行管理手段、共通処理手段の機能を、処理プログラムにより機能が特定される車両制御システムにより実現している。これに対し、上記複数の手段の機能の少なくとも一部を、回路構成自体で機能が特定されるハードウェアで実現してもよい。
【０１２７】
このように、本発明は、上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々の実施形態に適用可能である。
【符号の説明】
【０１２８】
１０、６０：車両制御システム、２０、７０：パワートレインＥＣＵ、２２、３２、４２、５２：制御処理手段、２４、３４、４４、５４：サブドメインＥＣＵ、７２、１１０：実行管理手段、７４、１１２：パラメータ記憶手段、１００：イントラボックス（共通処理手段、実行管理手段）、１２０：共通処理手段、１３０：監査手段、１４０：情報管理手段、１５０：変更判定手段、１６０：車上エネルギー管理手段、１７０：電子製品管理手段、２００、２０２、２０４、２０６、２１０、２１２、２１４、２１６、２２０、２２２、２２４、２２６：機能ドメインＥＣＵ
【特許請求の範囲】
【請求項１】
車両に搭載された複数の制御対象の挙動を制御するために複数の制御処理からなる車両制御を実行する制御処理手段と、
前記車両制御のライフサイクルを前記車両制御の機能に応じて設定するパラメータを記憶しているパラメータ記憶手段と、
を備え、
前記制御処理は、前記パラメータにより設定されるライフサイクルの長さに基づいて分類されている、
ことを特徴とする車両制御システム。
【請求項２】
複数の前記制御対象は前記制御対象の機能に応じて分類された機能ドメインに統合されており、
前記制御処理のライフサイクルの長さは前記機能ドメイン毎に前記パラメータにより設定されている、
ことを特徴とする請求項１に記載の車両制御システム。
【請求項３】
前記機能ドメインは前記制御対象の機能に応じて前記機能ドメインよりも詳細なサブドメインに分類されており、
前記制御処理のライフサイクルの長さは前記サブドメイン毎に前記パラメータにより設定されている、
ことを特徴とする請求項２に記載の車両制御システム。
【請求項４】
前記制御処理のライフサイクルの長さは、ユーザのニーズに基づいて前記パラメータにより設定されていることを特徴とする請求項１から３のいずれか一項に記載の車両制御システム。
【請求項５】
前記車両制御に共通する少なくとも一つの共通処理を実行する共通処理手段をさらに備え、
前記共通処理は、前記共通処理の機能に応じて前記パラメータにより設定された前記共通処理のライフサイクルの長さに基づいて分類されている、
ことを特徴とする請求項１から４のいずれか一項に記載の車両制御システム。
【請求項６】
前記共通処理のライフサイクルの長さは、技術的なライフサイクルに基づいて前記パラメータにより設定されていることを特徴とする請求項５に記載の車両制御システム。
【請求項７】
複数の前記共通処理の一つは、前記制御対象の挙動が正常であるか異常であるかを判定し、異常である場合に前記制御処理手段による前記制御対象に対する制御指令値を補正する監査処理であることを特徴とする請求項５または６に記載の車両制御システム。
【請求項８】
複数の前記共通処理の一つは、車両情報の安全性を管理する情報管理処理であることを特徴とする請求項５から７のいずれか一項に記載の車両制御システム。
【請求項９】
複数の前記共通処理の一つは、前記制御処理手段において変更可能なハードウェアまたはソフトウェアを特定する照合情報に基づいて前記ハードウェアまたは前記ソフトウェアの変更が適正であるか否かを判定する変更判定処理であり、前記変更判定処理のライフサイクルは前記照合情報のライフサイクルよりも長いことを特徴とする請求項５から８のいずれか一項に記載の車両制御システム。
【請求項１０】
複数の前記共通処理の一つは、前記制御処理手段におけるハードウェアまたはソフトウェアの変更が適正である場合、前記制御処理手段が接続する通信系の通信設定を調整する通信設定処理であることを特徴とする請求項９に記載の車両制御システム。
【請求項１１】
複数の前記共通処理の一つは、車両におけるエネルギーを管理する車上エネルギー管理処理であることを特徴とする請求項５から１０のいずれか一項に記載の車両制御システム。
【請求項１２】
複数の前記共通処理の一つは、前記制御処理手段に搭載された電子製品の余剰資源を管理する電子製品管理処理であることを特徴とする請求項５から１１のいずれか一項に記載の車両制御システム。
【請求項１３】
前記共通処理のライフサイクルは、車両のライフサイクル以上のロングサイクルと、車両のライフサイクルよりも短いショートサイクルとに分かれており、さらに前記ショートサイクルの長さに基づいて前記共通処理が分類されていることを特徴とする請求項５から１２のいずれか一項に記載の車両制御システム。
【請求項１４】
前記共通処理手段のうち、前記ロングサイクルの前記共通処理を実行する部分は、一つの処理装置に統合されていることを特徴とする請求項１３に記載の車両制御システム。
【請求項１５】
前記一つの処理装置に統合された前記共通処理手段のうち、冗長性が要求される部分をさらに別の処理装置に統合して冗長系を構成することを特徴とする請求項１４に記載の車両制御システム。
【請求項１６】
前記車両制御の実行を管理する実行管理手段をさらに備え、前記実行管理手段は、ライフサイクルに基づいて前記車両制御を実行する処理の実行順序を管理し、前記車両制御の起動時には、前記処理のうちライフサイクルの長い処理をライフサイクルの短い処理よりも先に起動し、前記車両制御の終了時には、前記処理のうちライフサイクルの長い処理をライフサイクルの短い処理よりも後に終了させることを特徴とする請求項１から１５のいずれか一項に記載の車両制御システム。
【請求項１７】
前記実行管理手段は、前記車両制御を実行する処理のうちいずれかの処理がリセットされると、リセットされた処理の実行が再開されるまで、リセットされた処理よりもライフサイクルの短い処理の実行を待機させることを特徴とする請求項１６に記載の車両制御システム。
【請求項１８】
前記車両制御を実行する処理手段は同じライフサイクルの前記車両制御を実行する処理毎にオブジェクト化されていることを特徴とする請求項１から１７のいずれか一項に記載の車両制御システム。
【請求項１】
車両に搭載された複数の制御対象の挙動を制御するために複数の制御処理からなる車両制御を実行する制御処理手段と、
前記車両制御のライフサイクルを前記車両制御の機能に応じて設定するパラメータを記憶しているパラメータ記憶手段と、
を備え、
前記制御処理は、前記パラメータにより設定されるライフサイクルの長さに基づいて分類されている、
ことを特徴とする車両制御システム。
【請求項２】
複数の前記制御対象は前記制御対象の機能に応じて分類された機能ドメインに統合されており、
前記制御処理のライフサイクルの長さは前記機能ドメイン毎に前記パラメータにより設定されている、
ことを特徴とする請求項１に記載の車両制御システム。
【請求項３】
前記機能ドメインは前記制御対象の機能に応じて前記機能ドメインよりも詳細なサブドメインに分類されており、
前記制御処理のライフサイクルの長さは前記サブドメイン毎に前記パラメータにより設定されている、
ことを特徴とする請求項２に記載の車両制御システム。
【請求項４】
前記制御処理のライフサイクルの長さは、ユーザのニーズに基づいて前記パラメータにより設定されていることを特徴とする請求項１から３のいずれか一項に記載の車両制御システム。
【請求項５】
前記車両制御に共通する少なくとも一つの共通処理を実行する共通処理手段をさらに備え、
前記共通処理は、前記共通処理の機能に応じて前記パラメータにより設定された前記共通処理のライフサイクルの長さに基づいて分類されている、
ことを特徴とする請求項１から４のいずれか一項に記載の車両制御システム。
【請求項６】
前記共通処理のライフサイクルの長さは、技術的なライフサイクルに基づいて前記パラメータにより設定されていることを特徴とする請求項５に記載の車両制御システム。
【請求項７】
複数の前記共通処理の一つは、前記制御対象の挙動が正常であるか異常であるかを判定し、異常である場合に前記制御処理手段による前記制御対象に対する制御指令値を補正する監査処理であることを特徴とする請求項５または６に記載の車両制御システム。
【請求項８】
複数の前記共通処理の一つは、車両情報の安全性を管理する情報管理処理であることを特徴とする請求項５から７のいずれか一項に記載の車両制御システム。
【請求項９】
複数の前記共通処理の一つは、前記制御処理手段において変更可能なハードウェアまたはソフトウェアを特定する照合情報に基づいて前記ハードウェアまたは前記ソフトウェアの変更が適正であるか否かを判定する変更判定処理であり、前記変更判定処理のライフサイクルは前記照合情報のライフサイクルよりも長いことを特徴とする請求項５から８のいずれか一項に記載の車両制御システム。
【請求項１０】
複数の前記共通処理の一つは、前記制御処理手段におけるハードウェアまたはソフトウェアの変更が適正である場合、前記制御処理手段が接続する通信系の通信設定を調整する通信設定処理であることを特徴とする請求項９に記載の車両制御システム。
【請求項１１】
複数の前記共通処理の一つは、車両におけるエネルギーを管理する車上エネルギー管理処理であることを特徴とする請求項５から１０のいずれか一項に記載の車両制御システム。
【請求項１２】
複数の前記共通処理の一つは、前記制御処理手段に搭載された電子製品の余剰資源を管理する電子製品管理処理であることを特徴とする請求項５から１１のいずれか一項に記載の車両制御システム。
【請求項１３】
前記共通処理のライフサイクルは、車両のライフサイクル以上のロングサイクルと、車両のライフサイクルよりも短いショートサイクルとに分かれており、さらに前記ショートサイクルの長さに基づいて前記共通処理が分類されていることを特徴とする請求項５から１２のいずれか一項に記載の車両制御システム。
【請求項１４】
前記共通処理手段のうち、前記ロングサイクルの前記共通処理を実行する部分は、一つの処理装置に統合されていることを特徴とする請求項１３に記載の車両制御システム。
【請求項１５】
前記一つの処理装置に統合された前記共通処理手段のうち、冗長性が要求される部分をさらに別の処理装置に統合して冗長系を構成することを特徴とする請求項１４に記載の車両制御システム。
【請求項１６】
前記車両制御の実行を管理する実行管理手段をさらに備え、前記実行管理手段は、ライフサイクルに基づいて前記車両制御を実行する処理の実行順序を管理し、前記車両制御の起動時には、前記処理のうちライフサイクルの長い処理をライフサイクルの短い処理よりも先に起動し、前記車両制御の終了時には、前記処理のうちライフサイクルの長い処理をライフサイクルの短い処理よりも後に終了させることを特徴とする請求項１から１５のいずれか一項に記載の車両制御システム。
【請求項１７】
前記実行管理手段は、前記車両制御を実行する処理のうちいずれかの処理がリセットされると、リセットされた処理の実行が再開されるまで、リセットされた処理よりもライフサイクルの短い処理の実行を待機させることを特徴とする請求項１６に記載の車両制御システム。
【請求項１８】
前記車両制御を実行する処理手段は同じライフサイクルの前記車両制御を実行する処理毎にオブジェクト化されていることを特徴とする請求項１から１７のいずれか一項に記載の車両制御システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−２１８００６（Ｐ２０１０−２１８００６Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２００９−６１２４６（Ｐ２００９−６１２４６）
【出願日】平成２１年３月１３日（２００９．３．１３）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２１年３月１３日（２００９．３．１３）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
[ Back to top ]