Vehicle control device and software components

申请号 JP2011289237 申请日 2011-12-28 公开(公告)号 JP5549665B2 公开(公告)日 2014-07-16
申请人 株式会社デンソー; 发明人 彩 中村; 正幸 小林;
摘要
权利要求
  • 入力に対して、機能安全規格に対応した出力を行う第1制御手段と、
    前記第1制御手段のソフトウェアを管理 し、前記機能安全規格に対応した第1プラットホームと、
    前記入力に対して、前記機能安全規格に非対応の出力を行う第2制御手段と、
    前記第2制御手段のソフトウェアを管理 し、前記機能安全規格に非対応の第2プラットホームと、
    前記第1制御手段の出力と前記第2制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、
    を備え、
    前記第1プラットホームと前記第2プラットホームとが、少なくとも、前記第1プラットホームによる前記第1制御手段のソフトウェアの管理と前記第2プラットホームによる前記第2制御手段のソフトウェアの管理とに関して独立していることを特徴とする車両制御装置。
  • 前記第1制御手段,前記第1プラットホーム,前記第2制御手段,前記第2プラットホーム,及び前記比較結合手段のいずれか1つ(但し、前記第2制御手段単独を除く)が、またはいずれか複数が協働することにより、前記第2制御手段に係る機能不全の発生を抑制することを特徴とする請求項1に記載の車両制御装置。
  • 前記第1制御手段,前記第1プラットホーム,前記第2制御手段,前記第2プラットホーム,及び前記比較結合手段のいずれか1つ(但し、前記第2制御手段単独を除く)が、またはいずれか複数が協働することにより、前記第2制御手段に係る機能不全が発生した場合に前記制御対象への出力を安全状態に移行させることを特徴とする請求項1に記載の車両制御装置。
  • 前記第1制御手段のソフトウェアは、前記第2制御手段のソフトウェアに係るプログラムのうち、前記機能安全規格に対応することが要求される機能に関連する部分を切り出して、前記機能安全規格に対応させて構成されたことを特徴とする請求項3に記載の車両制御装置。
  • 前記入力を前記第1制御手段または前記第1プラットホームを介して前記第2制御手段または前記第2プラットホームに入力する処理、前記第1制御手段及び前記第2制御手段に係る処理、前記比較結合手段に係る処理、の順で、処理が実行されることを特徴とする請求項1に記載の車両制御装置。
  • 前記第2制御手段に係る処理の一部または全部が、前記比較結合手段に係る処理以外の処理と前記比較結合手段に係る処理との間に実行されることを特徴とする請求項1に記載の車両制御装置。
  • 前記第1制御手段のソフトウェアに係るプログラムを取り外し可能に構成されたことを特徴とする請求項2〜6のいずれか1項に記載の車両制御装置。
  • 前記第1制御手段のソフトウェアに係るプログラムと前記第2制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、
    前記メモリは前記配置ブロック毎に配置アドレスを設定可能なことを特徴とする請求項2〜7のいずれか1項に記載の車両制御装置。
  • 入力に対して、機能安全規格に対応した出力を行う第1制御手段と、
    前記第1制御手段のソフトウェアを管理 し、前記機能安全規格に対応した第1プラットホームと、
    前記入力に対して、前記機能安全規格に非対応の出力を行う第2制御手段と、
    前記第2制御手段のソフトウェアを管理 し、前記機能安全規格に非対応の第2プラットホームと、
    前記第1制御手段の出力と前記第2制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、
    を備え、
    前記第2制御手段のソフトウェアとして既存のソフトウェアを、 前記第1制御手段のソフトウェアとして新規開発のソフトウェアを、それぞれ割り当てたことを特徴とする車両制御装置。
  • 前記第2制御手段及び前記第2プラットフォームのソフトウェアとして既存のソフトウェアを、第1制御手段及び前記第1プラットフォームのソフトウェアとして新規開発のソフトウェアを、それぞれ割り当てたことを特徴とする請求項9に記載の車両制御装置。
  • 前記第1制御手段のソフトウェアに係るプログラムを取り外し可能に構成されたことを特徴とする請求項10に記載の車両制御装置。
  • 前記第1制御手段のソフトウェアに係るプログラムと前記第2制御手段のソフトウェアに係るプログラムとが別ファイルで管理され、各々のファイルが取り外し可能とされたことを特徴とする請求項11に記載の車両制御装置。
  • 前記第1制御手段のソフトウェアに係るプログラムと前記第2制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、
    前記メモリは前記配置ブロック毎に前記プログラムを取り外し可能なことを特徴とする請求項11または12に記載の車両制御装置。
  • 入力に対して、機能安全規格に対応した出力を行う第1制御手段のソフトウェアに係るプログラムと、前記入力に対して、前記機能安全規格に非対応の出力を行う第2制御手段のソフトウェアに係るプログラムとを、 各プログラムの変数またはコンポーネントの少なくともいずれか一方をそれぞれ記憶した別ファイルで管理することを特徴とするソフトウェア部品。
  • 機能安全規格に対応したプラットホームのソフトウェアによって管理され、 前記機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアとは別に取り付け可能に構成されたことを特徴とするソフトウェア部品。
  • 請求項 14または15に記載のソフトウェア部品を備えたことを特徴とする車両制御装置。
  • 機能安全規格に対応したソフトウェアに係るプログラムを、 前記安全規格に対応したプラットホームのソフトウェアに対して取り付け可能に構成されたことを特徴とするソフトウェア部品。
  • 請求項 17に記載のソフトウェア部品を備えたことを特徴とする車両制御装置。
  • デイジーチェーンの接続元と接続先とを設定することで、機能安全規格に対応したソフトウェアに係るプログラムに接続可能なことを特徴とするソフトウェア部品。
  • 前記接続先を設定することで、請求項 19に記載のソフトウェア部品との接続を可能とすることを特徴とする請求項1に記載車両制御装置。
  • 说明书全文

    本発明は、車両制御装置及びソフトウェア部品に関し、詳しくは、機能安全規格に対応した制御を行う車両制御装置、及び、その車両制御装置を構成するのに利用可能なソフトウェア部品に関する。

    従来、ロボット,輸送機器等の各種装置では、当該装置の主たる動作・機能を実現するための制御と、当該装置の安全性を確保するための制御とが、並行して実行される場合がある(例えば、特許文献1参照)。

    特開2010−271759号公報

    ところが、そのような装置を制御する場合、装置の機能安全要求レベルや安全目標が変更されると、前記安全性を確保するための制御プログラムも作り直す必要が生じる。 ここで、自動車のドア開閉スイッチに関連する例を挙げて説明する。

    図1は、車両制御装置としての電動ドアECU1が、開閉スイッチECU3が検出した人Hによる前記ドア開閉スイッチの操作と、タイヤTの回転から車速計測ECU4が計測した車速とに基づき、ドアDの開閉等を制御する制御系の構成を表すブロック図である。 なお、本例の自動車は4つのドアDを備えており、以下、必要に応じて、左前に配置されたものをドアDFL,右前に配置されたものをドアDFR,左後に配置されたものをドアDRL,右後に配置されたものをドアDRRという。 ドアDFL,DFR,DRL,DRRは、それぞれ、開閉ドアECU5FL,5FR,5RL,5RRを介してその開閉(電動アクチュエータによる自動開閉)が制御される。 また、電動ドアECU1には、車内ライトECU5Lを介して車内ライトLが接続されている。

    図15は、電動ドアECU1のソフトウェア構成を模式的に表すブロック図である。 なお、電動ドアECU1は、ドア開閉スイッチの操作時に車内ライトLをLTIME時間点灯し、ドア開閉スイッチが操作されかつ車速が15km/h未満のときにドアDを開く処理を実行する制御を実行する。 そして、その場合、車内ライトLの点灯制御は機能安全規格に対応させる必要のないいわゆるQM部であるが、ドアDを開く制御はASIL−C等の機能安全規格に対応させる必要のあるいわゆるASIL部である。

    図15に示すように、電動ドアECU1は、ハードウェア資源として、制御に必要な各種演算を行う演算部1Aと、前述の開閉スイッチECU3,車速計測ECU4から入されるドア開閉スイッチの操作状態と車速とが入力される入力部1Bと、ドアDや車内ライトLに制御信号を出力する出力部1Cとを備えている。 次に、演算部1Aのソフトウェア構成ついて説明する。

    入力部1Bを介して入力されたドア開閉スイッチの操作状態や車速は、基盤ソフトウェア(すなわちプラットホーム)を構成するBSW(Basic SoftWare)10及びRTE(RunTime Environment)11を介してD入力部12,L入力部15に入力される。 演算部1Aは、ドアDを開く制御に関するアプリケーション(基盤ソフトウェア以外)として、ドア開閉スイッチの操作状態や車速が入力されるD入力部12と、その入力に対する演算を行うD演算部13と、その演算結果に応じてドア開命令を出力するD出力部14とを備えている。 また、演算部1Aは、車内ライトLの点灯制御に関するアプリケーション(基盤ソフトウェア以外)として、ドア開閉スイッチの操作状態や車速が入力されるL入力部15と、その入力に対する演算を行うL演算部16と、その演算結果に応じた車内ライト点灯命令を出力するL出力部17とを備えている。 D出力部14,L出力部17が出力出力した命令は、RTE11,BSW10を経由して出力部1Cに入力され、その出力部1Cを介して、前述の開閉ドアECU5FL,5FR,5RL,5RRや車内ライトECU5Lに向けて出力される。

    ここで、L入力部15,L演算部16,L出力部17は機能安全規格に対応させる必要のないいわゆるQM部であるが、D入力部12,D演算部13,D出力部14はASIL−C等の機能安全規格に対応させる必要のあるいわゆるASIL部である。 このため、新たな機能安全規格に対応するためには、少なくとも対応が要求された機能、すなわちD入力部12,D演算部13,D出力部14は、規格が要求する付随機能と開発プロセスとを満たすものに再開発する必要が生じる。 例えば、電動ドアECU1が機能安全規格に対応した場合、「15km/h以上でドアを開けられること」がハザードとされ、「15km/h以上の場合、ドアを開けないこと」がASIL−Cの安全目標とされる。 また、「車両速度が15km/h以下で、ドア開閉スイッチがONされたときに、ドアを開ける」の機能不全がハザードを引き起こすため、この機能にASIL−Cへの対応が要求される。 ASIL−C対応が要求される機能のソフトウェア(D入力部12,D演算部13,D出力部14)は、制御フローモニタリング等の付随機能と要求事項に対してインスペクションによるインフォーマルな整合性検証等が要求されるため、再開発が必要となる。

    この場合のソフトウェアは、既に開発していた「車両速度が15km/h以下で、ドア開閉スイッチがONされたときに、ドアを開ける」と基盤ソフトウェア(BSW10,RTE11)とを破棄して再開発を実施するため、差分開発に比べて開発コストが増加してしまう。 すなわち、D入力部12,D演算部13,D出力部14が機能安全規格に応じて再開発されることにより、それらの処理を管理するBSW10,RTE11も再開発する必要が生じる。 また、再開発により品質低下のリスクも発生する。

    そこで、本発明は、既存のソフトウェアを再利用しつつ新たな機能安全要求にも対応可能な車両制御装置、及び、その車両制御装置を構成するのに利用可能なソフトウェア部品を提供することを目的としてなされた。

    前記目的を達するためになされた本発明の車両制御装置は、入力に対して、機能安全規格に対応した出力を行う第1制御手段と、前記第1制御手段のソフトウェアを管理し、前記機能安全規格に対応した第1プラットホームと、前記入力に対して、前記機能安全規格に非対応の出力を行う第2制御手段と、前記第2制御手段のソフトウェアを管理し、前記機能安全規格に非対応の第2プラットホームと、前記第1制御手段の出力と前記第2制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、を備え、前記第1プラットホームと前記第2プラットホームとが、少なくとも、前記第1プラットホームによる前記第1制御手段のソフトウェアの管理と前記第2プラットホームによる前記第2制御手段のソフトウェアの管理とに関して独立していることを特徴としている。

    このように構成された本発明の車両制御装置では、第1制御手段は、そのソフトウェアが機能安全規格に対応した第1プラットホームに管理されており、入力に対して機能安全規格に対応した出力を行う。 一方、第2制御手段は、そのソフトウェアが機能安全規格に非対応の第2プラットホームに管理されており、入力に対して機能安全規格に非対応の出力を行う。 そして、比較結合手段は、前記第1制御手段の出力と前記第2制御手段の出力とを比較結合して制御対象に出力する。

    ここで、第1プラットホーム,第2プラットホームは、少なくとも、第1プラットホームによる第1制御手段のソフトウェアの管理と第2プラットホームによる第2制御手段のソフトウェアの管理とに関して独立している。 このため、第2制御手段及び第2プラットホームに既存のソフトウェアを割り当て、第1制御手段及び第1プラットホームを新たに追加したとしても、その追加に応じて第2制御手段及び第2プラットホームを変更する必要がない。 また、比較結合手段により第1制御手段の出力と第2制御手段の出力とを適切に比較結合すれば、全体として前記機能安全規格に対応した制御が可能となる。

    従って、本発明では、既存のソフトウェアを有効に再利用しつつ、新たな機能安全要求にも対応することができる。 更に、第1制御手段のソフトウェアを、機能安全規格に対応することが要求される機能に関連するもののみとすれば、当該ソフトウェアに係るプログラムを記憶するためのメモリ容量低減も可能となる。

    なお、本発明において、前記第1制御手段,前記第1プラットホーム,前記第2制御手段,前記第2プラットホーム,及び前記比較結合手段のいずれか1つ(但し、前記第2制御手段単独を除く)が、またはいずれか複数が協働することにより、前記第2制御手段に係る機能不全の発生を抑制してもよい。

    また、本発明において、前記第1制御手段,前記第1プラットホーム,前記第2制御手段,前記第2プラットホーム,及び前記比較結合手段のいずれか1つ(但し、前記第2制御手段単独を除く)が、またはいずれか複数が協働することにより、前記第2制御手段に係る機能不全が発生した場合に前記制御対象への出力を安全状態に移行させてもよい。

    また、その場合、前記第1制御手段のソフトウェアは、前記第2制御手段のソフトウェアに係るプログラムのうち、前記機能安全規格に対応することが要求される機能に関連するもののみを切り出して、前記機能安全規格に対応させて構成されてもよい。 この場合、デコンポジションを活用し、第2制御手段のソフトウェアに係るプログラムのうちの前記機能安全規格に対応することが要求される機能に関連するもののみを切り出して前記機能安全規格に対応させたものが、第1制御手段のソフトウェアを構成するため、そのソフトウェアに係るプログラムを記憶するためのメモリ容量を低減することができる。

    すなわち、機能安全規格への対応が要求される機能は、付随機能の追加を実施するため、プログラムサイズが大きくなり、機能安全規格への対応が要求されない制御装置に移植して再利用した場合、プログラムメモリが大きい高価なマイクロコンピュータ(以下マイコンという)を利用しなければならなくなるが、本発明を前記のように構成した場合はプログラムメモリの小さい安価なマイコンを利用することができる。

    また、本発明において、前記入力を前記第1制御手段または前記第1プラットホームを介して前記第2制御手段または前記第2プラットホームに入力する処理、前記第1制御手段及び前記第2制御手段に係る処理、前記比較結合手段に係る処理、の順で、処理が実行されてもよい。 また、本発明において、前記第2制御手段に係る処理の一部または全部が、前記比較結合手段に係る処理以外の処理と前記比較結合手段に係る処理との間に実行されてもよい。

    また、本発明において、前記第1制御手段のソフトウェアに係るプログラム(すなわちASIL部)を取り外し可能に構成されてもよい。 その場合、ASIL部を新たな機能安全要求に対応したものとするのが一層容易となる。

    また、本発明において、前記第1制御手段のソフトウェアに係るプログラムと前記第2制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、前記メモリは前記配置ブロック毎に配置アドレスを設定可能であってもよい。

    また、本発明の車両制御装置は、複数のシーケンスモニタの有効範囲を前記各シーケンスモニタ間でオーバーラップさせたことを特徴とするものであってもよい。 その場合、複数のシーケンスモニタ間で有効範囲がオーバーラップしているので、当該複数のシーケンスモニタによるチェックをもれなく行うことができる。

    また、本発明の車両制御装置は、入力に対して、機能安全規格に対応した出力を行う第1制御手段と、前記第1制御手段のソフトウェアを管理し、前記機能安全規格に対応した第1プラットホームと、前記入力に対して、前記機能安全規格に非対応の出力を行う第2制御手段と、前記第2制御手段のソフトウェアを管理し、前記機能安全規格に非対応の第2プラットホームと、前記第1制御手段の出力と前記第2制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、を備え、前記第2制御手段のソフトウェアとして既存のソフトウェアを、第1制御手段のソフトウェアとして新規開発のソフトウェアを、それぞれ割り当てたことを特徴とするものであってもよい。 この場合も、既存のソフトウェアを再利用することにより、開発コストを低減することができる。

    そして、その場合、前記第1制御手段のソフトウェアに係るプログラム(すなわちASIL部)を取り外し可能に構成されてもよい。 その場合、ASIL部を新たな機能安全規格に対応したものとするのが一層容易となる。

    そして、その場合、前記第1制御手段のソフトウェアに係るプログラムと前記第2制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、前記メモリは前記配置ブロック毎に前記プログラムを取り外し可能であってもよい。 その場合、前記第1制御手段のソフトウェアに係るプログラムの取り外しが、配置ブロックの取り外し(削除等)によって一層容易に実行できる。

    また、その場合、前記第1制御手段のソフトウェアに係るプログラムと前記第2制御手段のソフトウェアに係るプログラムとが別ファイルで管理され、各々のファイルが取り外し可能とされていてもよい。 その場合、前記第1制御手段のソフトウェアに係るプログラムの取り外しが、ファイルの取り外し(削除等)によって一層容易に実行できる。

    また、前記目的を達するためになされた本発明のソフトウェア部品は、入力に対して、機能安全規格に対応した出力を行う第1制御手段のソフトウェアに係るプログラムと、前記入力に対して、前記機能安全規格に非対応の出力を行う第2制御手段のソフトウェアに係るプログラムとに分けて管理することを特徴としている。 その管理方法として、 各プログラムの変数またはコンポーネントの少なくともいずれか一方をそれぞれ記憶した別ファイルでの管理を挙げている。 このように構成されたソフトウェア部品では、第2制御手段のソフトウェアに係るプログラム(例えばQM部)を再利用することが容易になる。

    また、前記目的達するためになされた本発明のソフトウェア部品は、 機能安全規格に対応したプラットホームのソフトウェアによって管理され、 前記機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアとは別に取り付け可能に構成されたことを特徴とするものであってもよい。 このように構成されたソフトウェア部品を利用すれば、機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアに当該ソフトウェアとは別のソフトウェアとして取り付けることによって、既存のソフトウェアを有効に再利用しつつ、新たな機能安全要求にも対応することができる。

    そして、前記目的達するためになされた本発明の車両制御装置は、前記いずれかのソフトウェア部品を備えたことを特徴とするものであってもよい。
    また、前記目的達するためになされた本発明のソフトウェア部品は、機能安全規格に対応したソフトウェアに係るプログラムを、 前記機能安全規格に対応したプラットホームのソフトウェアに対して取り付け可能に構成されたことを特徴とするものであってもよい。 このように構成されたソフトウェア部品を利用すれば、機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアに対して取り付けることによって、既存のソフトウェアを有効に再利用しつつ、新たな機能安全要求にも対応することができる。

    そして、前記目的達するためになされた本発明の車両制御装置は、前記ソフトウェア部品を備えたことを特徴とするものであってもよい。
    また、前記目的達するためになされた本発明のソフトウェア部品は、デイジーチェーンの接続元と接続先とを設定することで、機能安全規格に対応したソフトウェアに係るプログラムに接続可能なことを特徴とするものであってもよい。

    そして、前記車両制御装置は、前記接続先を設定することで、前記ソフトウェア部品との接続を可能とするものであってもよい。

    本発明を適用可能な制御系の構成を表すブロック図である。

    その制御系に適用した実施形態の電動ドアECUを表すブロック図である。

    その電動ドアECUと開閉ドアECU、車内ライトECUにおける処理を表すフローチャートである。

    その処理におけるBSW間の送信処理を表すフローチャートである。

    前記処理における機能安全対応処理を表すフローチャートである。

    前記処理における機能安全非対応処理を表すフローチャートである。

    前記処理における比較結合処置の処理を表すフローチャートである。

    前記処理における機能安全対応を要しない処理を表すフローチャートである。

    前記電動ドアECUにおけるデータ配置を表す模式図である。

    前記電動ドアECUの診断コンポーネントを表すブロック図である。

    当該診断コンポーネントの要部を詳細に表すブロック図である。

    前記電動ドアECUにおけるコンポーネント配置を表す模式図である。

    前記電動ドアECUにおけるシーケンス&時間モニタの一例を表す説明図である。

    前記電動ドアECUにおける読み書き&演算モニタの一例を表す説明図である。

    前記制御系に適用した比較例の電動ドアECUを表すブロック図である。

    [車両制御装置の全体構成]
    次に、本発明の実施形態を図面と共に説明する。 なお、本実施形態の車両制御装置としての電動ドアECU100も、前述の図1に示した制御系に電動ドアECU1の代わりに用いられる。 図2は、電動ドアECU100のソフトウェア構成を模式的に表すブロック図である。 なお、電動ドアECU100は、ドア開閉スイッチの操作時に車内ライトLをLTIME時間点灯し、ドア開閉スイッチが操作されかつ車速が15km/h未満のときにドアDを開く処理を実行する制御を、ASIL−Cに従って実行する。

    図2に示すように、電動ドアECU100は、ハードウェア資源として、制御に必要な各種演算を行う演算部100Aと、前述の開閉スイッチECU3,車速計測ECU4から入力されるドア開閉スイッチの操作状態と車速とが入力される入力部100Bと、ドアDや車内ライトLに制御信号を出力する出力部100Cとを備えている。 次に、演算部100Aのソフトウェア構成ついて説明する。

    演算部100Aも、前述の演算部1Aと同様の、BSW10,RTE11,D入力部12,D演算部13,D出力部14,L入力部15,L演算部16,L出力部17を備えている。 そして、演算部100Aは、機能安全規格としてのASIL−Cに対応したD入力部112,D演算部113,D出力部114を、ASIL−Cに非対応のD入力部12,D演算部13,D出力部14と並列に備えている。 また、BSW10やRTE11はこれらのD入力部112,D演算部113,D出力部114の管理に対応していない。 そこで、演算部100Aは、D入力部112,D演算部113,D出力部114をBSW10,RTE11とは独立して管理するBSW110,RTE111も、BSW10,RTE11と並列に備えている。

    また、D入力部112,D演算部113,D出力部114は、D入力部12,D演算部13,D出力部14のうちASIL−Cに対応することが要求される部分だけを切り出して、ASIL−Cに対応させたものである。 従って、図2に矢印で示したように、D入力部112,D演算部113,D出力部114に係るメモリ容量を低減することができ、それらを管理するBSW110,RTE111に係るメモリ容量も低減することができる。

    なお、前記構成において、BSW10,RTE11が第2プラットホームに、D入力部12,D演算部13,D出力部14,L入力部15,L演算部16,L出力部17が第2制御手段に、D入力部112,D演算部113,D出力部114が第1制御手段に、BSW110,RTE111が第1プラットホームに、RTE111が比較結合手段に、それぞれ対応する。

    [車両制御装置における処理]
    図3のS1〜S9は、電動ドアECU100において所定時間毎に繰り返し実行される処理を表すフローチャートである。 図3に示すように、この処理で、電動ドアECU100は、先ずS1にて(Sはステップを表す:以下同様)、機能安全規格に対応したBSW110から機能安全規格に非対応のBSW10への送信が実行される。 図4は、その送信処理を詳細に表すフローチャートである。 なお、この処理は、主としてBSW110によって実行される。

    図4に示すように、この送信処理では、先ず、S11にて、入力部100Bが前述の開閉スイッチECU3(図1参照)等から受信した変数SREQ2,SSW1,SSW1Sが、当該入力部100Bから受信される。 なお、変数SREQ2は、ドアDに対する何らかの要求有無を表す変数で、SSW1はドア開閉スイッチのON/OFF状態を表す変数で、SSW1Sは(ドア開/ドア閉)を表す変数である。 続くS13では、前記SREQ2,SSW1,SSW1Sが、REQ2,SW1,SW1Sとして、BSW110からBSW10へ送信され、処理は図3のS3へ移行する。

    図3へ戻って、S3では、機能安全規格に対応した、後述の比較結合処置(S7)以外の処理が実行される。 図5は、その処理を詳細に表すフローチャートである。 なお、この処理は、主としてD演算部113によって実行される。

    図5に示すように、この処理では、先ず、S31にて、変数SREQ2が要求なしにセットされ、続くS33にて、変数SSW1がONとなっているか否か、すなわち、前記ドア開閉スイッチがONされているか否かが判断される。 SSW1=OFFの場合は(S33:N)、車両としての処理がそのまま一旦終了し(図3参照)、SSW1=ONの場合は(S33:Y)、処理はS35へ移行する。 S35では、変数SREQ2が要求ありにセットされ、S37にて、変数SSW1Sの値が変数SOPN2Rに代入される。

    続くS39では、車速(SPEED)が15km/h未満であるか否かが判断され、SPEED<15km/hの場合はそのまま(S39:Y)、SPEED≧15km/hの場合は(S39:N)、S41にて変数SREQ2が要求なしにセットされた後、処理は図3のS5へ移行する。

    図3へ戻って、S5では、機能安全規格への対応を要求された機能を含む従来のソフトウェア処理が実行される。 図6は、その処理を詳細に表すフローチャートである。 なお、この処理は、主としてD演算部13によって実行される。

    図6に示すように、この処理では、先ず、S51にて、変数REQ2が要求なしにセットされ、続くS53にて、変数SW1がONとなっているか否か、すなわち、前記ドア開閉スイッチがONされているか否かが判断される。 SW1=OFFの場合は(S53:N)、車両としての処理がそのまま一旦終了し(図3参照)、SW1=ONの場合は(S53:Y)、処理はS55へ移行する。 S55では、変数REQ2が要求ありにセットされ、S57にて、変数SW1SがONであるか否かが判断される。

    SW1S=ONの場合は(S57:Y)、S58にて変数OPN2Rが開にセットされ、続くS59では、車速(SPEED)が15km/h未満であるか否かが判断される。 そして、SPEED<15km/hの場合はそのまま(S59:Y)、SPEED≧15km/hの場合は(S59:N)、S61にて変数REQ2が要求なしにセットされた後、処理は図3のS7へ移行する。 また、S57にてSW1S≠ONと判断された場合は(S57:N)、S63にて変数OPEN2Rが閉にセットされて、処理は図3のS7へ移行する。

    図3へ戻って、S7では、機能安全規格に対応した比較結合処置の処理が実行される。 図7はその処理を表すフローチャートである。 なお、この処理は、主としてRTE111によって実行される。

    図7に示すように、この処理では、先ず、S71にて、変数SREQ2の値が変数Aに、変数REQ2の値が変数Bに、それぞれ代入される。 続くS73では、A=Bであるか否かが判断され、A=Bである場合は(S73:Y)、処理はS75へ移行する。 S75では、変数SOPN2Rの値が変数Aに、変数OPN2Rの値が変数Bに、それぞれ代入される。 続くS77では、A=Bであるか否かが判断され、A=Bである場合は(S77:Y)、処理はS79へ移行する。 S79では、変数SREQ2,SOPN2Rの値が出力部100Cに送られ、処理は図3のS9へ移行する。

    一方、S73またはS77にてA≠Bと判断された場合は(S73:NまたはS77:N)、S81にてSREQ2が要求なしにセットされて、処理は前述のS79へ移行する。 すなわち、ドアDを開く制御はハザードとなり得るため、D演算部13,113の演算結果が完全に一致しない場合(例えばD演算部13の機能不全が生じた場合)は、出力を安全状態に移行させるのである。

    図3へ戻って、S9では、機能安全規格への対応を要求された機能を含まない従来のソフトウェア処理が実行される。 図8は、その処理を表すフローチャートである。 なお、この処理は、主としてL演算部16によって実行される。

    図8に示すように、この処理では、先ず、S91にて、LTIMEが15秒に設定される。 続くS93では、S91にて設定されたLTIMEが出力部100Cに送られ、処理は図3のS21へ移行する。 なお、図3のS21以降の処理は、開閉ドアECU5によって実行される。

    図3に示すように、S21では、前述のS79にて送信された変数SREQ2,SOPN2Rの値が開閉ドアECU5によって受信され、続くS23にて、変数SREQ2がON(すなわち要求あり)にセットされているか否かが判断される。 SREQ2≠ONの場合は(S23:N)、車両としての処理がそのまま一旦終了し、SREQ2=ONの場合は(S23:Y)、処理はS25へ移行する。 S25では、変数SOPN2Rが開にセットされているか否かが判断される。 SOPN2R=開のときは(S25:Y)、S26にてドアDを開く制御がなされた後、SOPN2R≠開のときは(S25:N)、S27にてドアDを閉じる制御がなされた後、それぞれ処理はS28へ移行する。

    S28では、前述のS93にて送信されたLTIMEの値が車内ライトECU5Lによって受信され、続くS29にて、車内ライトLをLTIME時間だけON(点灯)する制御が実行されて、車両としての処理が一旦終了する。 このように、本実施形態では、既存のソフトウェアを有効に再利用しつつ、全体として新たな機能安全要求にも対応することができる。 しかも、本実施形態では、新たな機能安全規格対応して追加した構成は、その機能安全規格への対応が要求された機能に係るプログラムのうちの、前記機能安全規格に対応することが要求される機能に関するもののみを切り出して前記機能安全規格に対応させたものであるので、当該プログラムを記憶するためのメモリ容量を低減することもできる。 また、BSW10〜L出力部17として既存のソフトウェアを再利用しているので、電動ドアECU100の開発コストも低減することができる。

    すなわち、本実施形態では、D入力部12,D演算部13,D出力部14(以下ASIL部という)を付随機能と付随機能以外に分離し、付随機能を取り付け可能とすることで、付随機能を再利用している。

    また、RTE111,BSW110に対するソフトウェアの接続順序や、当該接続されたソフトウェアの実行順序は可変であってもよい。 更に、D入力部112、D演算部113、D出力部114は、基盤ソフトウェア以外として次に列挙するような付随機能を有している。
    a)ソフトウェアのプログラムの実行順序を監視するシーケンスモニタとしての機能。
    b)ソフトウェアのプログラムの実行時間を監視する時間モニタとしての機能。
    c)ソフトウェアのデータの読み込みと書き出しを監視する読み書きモニタとしての機能。
    d)ソフトウェアのデータの演算を監視する演算モニタとしての機能。

    そして、それらの機能を実現するための取り付け手法としては、次に列挙するようなものが考えられる。
    a)プログラムの接続情報と順序識別子の可変設定を可能とするシーケンスモニタを構成する。
    b)プログラムの実行時間の可変設定を可能とする時間モニタを構成する。
    c)監視するデータの指定を可変とする読み書きモニタを構成する。
    d)監視するデータ(演算への入力データ、演算の出力データ)の指定を可変とする演算モニタを構成する。

    また、RTE111,BSW110は、基盤ソフトウェアとして次に列挙するような付随機能を有している。
    e)通信接続を監視するネットワーク接続モニタとしての機能。
    f)通信プログラムの実行時間を監視するネットワーク時間モニタとしての機能。
    g)通信データの読み込みと書き出しを監視するネットワーク読み書きモニタとしての機能。

    そして、それらの機能を実現するための取り付け手法としては、次に列挙するようなものが考えられる。
    e)通信の接続情報の可変設定を可能とするネットワーク接続モニタを構成する。
    f)通信プログラムの実行時間の可変設定を可能とするネットワーク時間モニタを構成する。
    g)通信データの指定を可変とするネットワーク読み書きモニタを構成する。

    また、本実施形態では、機能不全の検出をコンピュータの基本動作である以下の3点に絞ることで、付随機能のプログラムサイズを抑えることが可能となる。
    (1)プログラム順序に従ったステップ実行(プログラム実行):シーケンスモニタ、時間モニタ、ネットワーク接続モニタ、ネットワーク時間モニタ(2)データの読み出し・書き出し(データ保存):読み書きモニタ(3)データの演算(データ演算):演算モニタ 以下、それらの機能実現に関する構成について説明する。 図9に示すように、電動ドアECU100では、既存のBSW10〜L出力部17に係るプログラムの変数を記憶したブロックD1,D2,D3と、ASIL−Cに対応したBSW110〜D出力部114に係るプログラムの変数を記憶したブロックD4,D5,D6,D7と、を異なる配置ブロックに記憶したメモリを備え、前記メモリは前記配置ブロック毎に前記変数を取り外し可能に構成されている。 このため、ASIL−Cに対応したプログラムの取り外しが、配置ブロックの取り外し(削除等)によって一層容易に実行できる。 従って、新たな機能安全要求に対応した電動ドアECU100も容易に開発することができる。 なお、配置ブロックの代わりに、ファイルが取り外し可能とされていてもよい。 その場合、ASIL−Cに対応したプログラムの取り外しが、ファイルの取り外し(削除等)によって一層容易に実行できる。

    次に、図10は、電動ドアECU100の診断コンポーネントを表すブロック図である。 図10に示すように、この診断コンポーネントは、互いに連接された制御コンポーネント診断機能部210及び制御コンポーネント220と、制御コンポーネント220から演算すべきデータを受信して演算結果を制御コンポーネント220へ返す演算コンポーネント230と、制御コンポーネント220への外部からのデータの入出力に使用される入出力コンポーネント240と、制御コンポーネント220がメモリとして使用するメモリコンポーネント250とを備えている。

    また、制御コンポーネント診断機能部210は、演算コンポーネント230に入力されたデータとその演算結果とを入力されて診断を行う演算部診断部214と、制御コンポーネント220に設けられ第1Fun221,第2Fun222,第3Fun223の出力を入力されて制御コンポーネント220の診断を行う制御部診断部215と、メモリコンポーネント250に入出力されるデータを入力されてメモリコンポーネント250の診断を行うメモリ部診断部216とを備えている。 なお、第1Fun221〜第3Fun223は、順次実行されることにより、機能が所定の実行順序で、かつ、所定の実行時間実行されているかを検出するためのシーケンスモニタである。

    そして、図11に示すように、第1Fun221〜第3Fun223では、モニタ範囲が矢印Aで示すようにオーバーラップしているので、チェックをもれなく行うことができる。 なお、シーケンスモニタの有効範囲とネットワーク接続の有効範囲とがオーバーラップしてもよく、その場合も、シーケンスモニタによるチェックをもれなく行うことができる。

    また、このような各種コンポーネントC1,C2,C3,…も、図12に例示するように、メモリの異なる配置ブロックに記憶され、そのメモリは前記配置ブロック毎に前記コンポーネントCを取り外し可能に構成されている。 このため、ASIL−Cに対応したプログラムの取り外しが、配置ブロックの取り外し(削除等)によって一層容易に実行できる。 従って、新たな機能安全規格に対応した電動ドアECU100も容易に開発することができる。 なお、配置ブロックの代わりに、ファイルが取り外し可能とされていてもよい。 その場合、ASIL−Cに対応したコンポーネントの取り外しが、ファイルの取り外し(削除等)によって一層容易に実行できる。

    また、参考のため、電動ドアECU100のソフトウェアに係るプログラムリストを例示する。 図13(A)は、シーケンス&時間モニタの関数定義を例示しており、図13(B)は、シーケンス&時間モニタの使用箇所を例示している。 また、図14(A)は、読み書き&演算モニタの関数定義を例示しており、図14(B)は、読み書き&演算モニタの使用箇所を例示している。

    なお、本発明は前記実施形態に何ら限定されるものではなく、本発明の要旨を逸脱しない範囲で種々の形態で実施することができる。 例えば、電動ドアECU100は、車内ライトLの制御を行わず、ドアDを開く制御のみを実行するものであってもよく、その場合にも前述のような作用・効果が発揮される。

    1,100…電動ドアECU 1A,100A…演算部 1B,100B…入力部1C,100C…出力部 10,110…BSW 11,111…RTE
    12,112…D入力部 13,113…D演算部 14,114…D出力部15…L入力部 16…L演算部 17…L出力部210…制御コンポーネント診断機能部 214…演算部診断部215…制御部診断部 216…メモリ部診断部 220…制御コンポーネント221…第1Fun 222…第2Fun 223…第3Fun
    230…演算コンポーネント 240…入出力コンポーネント250…メモリコンポーネント DFL,DFR,DRL,DRR…ドアL…車内ライト

    QQ群二维码
    意见反馈