(57)【特許請求の範囲】
【請求項１】
入力に対して、機能安全規格に対応した出力を行う第１制御手段と、
前記第１制御手段のソフトウェアを管理し、前記機能安全規格に対応した第１プラットホームと、
前記入力に対して、前記機能安全規格に非対応の出力を行う第２制御手段と、
前記第２制御手段のソフトウェアを管理し、前記機能安全規格に非対応の第２プラットホームと、
前記第１制御手段の出力と前記第２制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、
を備え、
前記第１プラットホームと前記第２プラットホームとが、少なくとも、前記第１プラットホームによる前記第１制御手段のソフトウェアの管理と前記第２プラットホームによる前記第２制御手段のソフトウェアの管理とに関して独立していることを特徴とする車両制御装置。
【請求項２】
前記第１制御手段，前記第１プラットホーム，前記第２制御手段，前記第２プラットホーム，及び前記比較結合手段のいずれか１つ（但し、前記第２制御手段単独を除く）が、またはいずれか複数が協働することにより、前記第２制御手段に係る機能不全の発生を抑制することを特徴とする請求項１に記載の車両制御装置。
【請求項３】
前記第１制御手段，前記第１プラットホーム，前記第２制御手段，前記第２プラットホーム，及び前記比較結合手段のいずれか１つ（但し、前記第２制御手段単独を除く）が、またはいずれか複数が協働することにより、前記第２制御手段に係る機能不全が発生した場合に前記制御対象への出力を安全状態に移行させることを特徴とする請求項１に記載の車両制御装置。
【請求項４】
前記第１制御手段のソフトウェアは、前記第２制御手段のソフトウェアに係るプログラムのうち、前記機能安全規格に対応することが要求される機能に関連する部分を切り出して、前記機能安全規格に対応させて構成されたことを特徴とする請求項３に記載の車両制御装置。
【請求項５】
前記入力を前記第１制御手段または前記第１プラットホームを介して前記第２制御手段または前記第２プラットホームに入力する処理、前記第１制御手段及び前記第２制御手段に係る処理、前記比較結合手段に係る処理、の順で、処理が実行されることを特徴とする請求項１に記載の車両制御装置。
【請求項６】
前記第２制御手段に係る処理の一部または全部が、前記比較結合手段に係る処理以外の処理と前記比較結合手段に係る処理との間に実行されることを特徴とする請求項１に記載の車両制御装置。
【請求項７】
前記第１制御手段のソフトウェアに係るプログラムを取り外し可能に構成されたことを特徴とする請求項２〜６のいずれか１項に記載の車両制御装置。
【請求項８】
前記第１制御手段のソフトウェアに係るプログラムと前記第２制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、
前記メモリは前記配置ブロック毎に配置アドレスを設定可能なことを特徴とする請求項２〜７のいずれか１項に記載の車両制御装置。
【請求項９】
入力に対して、機能安全規格に対応した出力を行う第１制御手段と、
前記第１制御手段のソフトウェアを管理し、前記機能安全規格に対応した第１プラットホームと、
前記入力に対して、前記機能安全規格に非対応の出力を行う第２制御手段と、
前記第２制御手段のソフトウェアを管理し、前記機能安全規格に非対応の第２プラットホームと、
前記第１制御手段の出力と前記第２制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、
を備え、
前記第２制御手段のソフトウェアとして既存のソフトウェアを、前記第１制御手段のソフトウェアとして新規開発のソフトウェアを、それぞれ割り当てたことを特徴とする車両制御装置。
【請求項１０】
前記第２制御手段及び前記第２プラットフォームのソフトウェアとして既存のソフトウェアを、第１制御手段及び前記第１プラットフォームのソフトウェアとして新規開発のソフトウェアを、それぞれ割り当てたことを特徴とする請求項９に記載の車両制御装置。
【請求項１１】
前記第１制御手段のソフトウェアに係るプログラムを取り外し可能に構成されたことを特徴とする請求項１０に記載の車両制御装置。
【請求項１２】
前記第１制御手段のソフトウェアに係るプログラムと前記第２制御手段のソフトウェアに係るプログラムとが別ファイルで管理され、各々のファイルが取り外し可能とされたことを特徴とする請求項１１に記載の車両制御装置。
【請求項１３】
前記第１制御手段のソフトウェアに係るプログラムと前記第２制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、
前記メモリは前記配置ブロック毎に前記プログラムを取り外し可能なことを特徴とする請求項１１または１２に記載の車両制御装置。
【請求項１４】
入力に対して、機能安全規格に対応した出力を行う第１制御手段のソフトウェアに係るプログラムと、前記入力に対して、前記機能安全規格に非対応の出力を行う第２制御手段のソフトウェアに係るプログラムとを、各プログラムの変数またはコンポーネントの少なくともいずれか一方をそれぞれ記憶した別ファイルで管理することを特徴とするソフトウェア部品。
【請求項１５】
機能安全規格に対応したプラットホームのソフトウェアによって管理され、前記機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアとは別に取り付け可能に構成されたことを特徴とするソフトウェア部品。
【請求項１６】
請求項１４または１５に記載のソフトウェア部品を備えたことを特徴とする車両制御装置。
【請求項１７】
機能安全規格に対応したソフトウェアに係るプログラムを、前記安全規格に対応したプラットホームのソフトウェアに対して取り付け可能に構成されたことを特徴とするソフトウェア部品。
【請求項１８】
請求項１７に記載のソフトウェア部品を備えたことを特徴とする車両制御装置。
【請求項１９】
デイジーチェーンの接続元と接続先とを設定することで、機能安全規格に対応したソフトウェアに係るプログラムに接続可能なことを特徴とするソフトウェア部品。
【請求項２０】
前記接続先を設定することで、請求項１９に記載のソフトウェア部品との接続を可能と
することを特徴とする請求項１に記載車両制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両制御装置及びソフトウェア部品に関し、詳しくは、機能安全規格に対応した制御を行う車両制御装置、及び、その車両制御装置を構成するのに利用可能なソフトウェア部品に関する。
【背景技術】
【０００２】
従来、ロボット，輸送機器等の各種装置では、当該装置の主たる動作・機能を実現するための制御と、当該装置の安全性を確保するための制御とが、並行して実行される場合がある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−２７１７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところが、そのような装置を制御する場合、装置の機能安全要求レベルや安全目標が変更されると、前記安全性を確保するための制御プログラムも作り直す必要が生じる。ここで、自動車のドア開閉スイッチに関連する例を挙げて説明する。
【０００５】
図１は、車両制御装置としての電動ドアＥＣＵ１が、開閉スイッチＥＣＵ３が検出した人Ｈによる前記ドア開閉スイッチの操作と、タイヤＴの回転から車速計測ＥＣＵ４が計測した車速とに基づき、ドアＤの開閉等を制御する制御系の構成を表すブロック図である。なお、本例の自動車は４つのドアＤを備えており、以下、必要に応じて、左前に配置されたものをドアＤＦＬ，右前に配置されたものをドアＤＦＲ，左後に配置されたものをドアＤＲＬ，右後に配置されたものをドアＤＲＲという。ドアＤＦＬ，ＤＦＲ，ＤＲＬ，ＤＲＲは、それぞれ、開閉ドアＥＣＵ５ＦＬ，５ＦＲ，５ＲＬ，５ＲＲを介してその開閉（電動アクチュエータによる自動開閉）が制御される。また、電動ドアＥＣＵ１には、車内ライトＥＣＵ５Ｌを介して車内ライトＬが接続されている。
【０００６】
図１５は、電動ドアＥＣＵ１のソフトウェア構成を模式的に表すブロック図である。なお、電動ドアＥＣＵ１は、ドア開閉スイッチの操作時に車内ライトＬをＬＴＩＭＥ時間点灯し、ドア開閉スイッチが操作されかつ車速が１５ｋｍ／ｈ未満のときにドアＤを開く処理を実行する制御を実行する。そして、その場合、車内ライトＬの点灯制御は機能安全規格に対応させる必要のないいわゆるＱＭ部であるが、ドアＤを開く制御はＡＳＩＬ−Ｃ等の機能安全規格に対応させる必要のあるいわゆるＡＳＩＬ部である。
【０００７】
図１５に示すように、電動ドアＥＣＵ１は、ハードウェア資源として、制御に必要な各種演算を行う演算部１Ａと、前述の開閉スイッチＥＣＵ３，車速計測ＥＣＵ４から入力されるドア開閉スイッチの操作状態と車速とが入力される入力部１Ｂと、ドアＤや車内ライトＬに制御信号を出力する出力部１Ｃとを備えている。次に、演算部１Ａのソフトウェア構成ついて説明する。
【０００８】
入力部１Ｂを介して入力されたドア開閉スイッチの操作状態や車速は、基盤ソフトウェア（すなわちプラットホーム）を構成するＢＳＷ（Ｂａｓｉｃ  ＳｏｆｔＷａｒｅ）１０及びＲＴＥ（ＲｕｎＴｉｍｅ  Ｅｎｖｉｒｏｎｍｅｎｔ）１１を介してＤ入力部１２，Ｌ入力部１５に入力される。演算部１Ａは、ドアＤを開く制御に関するアプリケーション（基盤ソフトウェア以外）として、ドア開閉スイッチの操作状態や車速が入力されるＤ入力部１２と、その入力に対する演算を行うＤ演算部１３と、その演算結果に応じてドア開命令を出力するＤ出力部１４とを備えている。また、演算部１Ａは、車内ライトＬの点灯制御に関するアプリケーション（基盤ソフトウェア以外）として、ドア開閉スイッチの操作状態や車速が入力されるＬ入力部１５と、その入力に対する演算を行うＬ演算部１６と、その演算結果に応じた車内ライト点灯命令を出力するＬ出力部１７とを備えている。Ｄ出力部１４，Ｌ出力部１７が出力出力した命令は、ＲＴＥ１１，ＢＳＷ１０を経由して出力部１Ｃに入力され、その出力部１Ｃを介して、前述の開閉ドアＥＣＵ５ＦＬ，５ＦＲ，５ＲＬ，５ＲＲや車内ライトＥＣＵ５Ｌに向けて出力される。
【０００９】
ここで、Ｌ入力部１５，Ｌ演算部１６，Ｌ出力部１７は機能安全規格に対応させる必要のないいわゆるＱＭ部であるが、Ｄ入力部１２，Ｄ演算部１３，Ｄ出力部１４はＡＳＩＬ−Ｃ等の機能安全規格に対応させる必要のあるいわゆるＡＳＩＬ部である。このため、新たな機能安全規格に対応するためには、少なくとも対応が要求された機能、すなわちＤ入力部１２，Ｄ演算部１３，Ｄ出力部１４は、規格が要求する付随機能と開発プロセスとを満たすものに再開発する必要が生じる。例えば、電動ドアＥＣＵ１が機能安全規格に対応した場合、「１５ｋｍ／ｈ以上でドアを開けられること」がハザードとされ、「１５ｋｍ／ｈ以上の場合、ドアを開けないこと」がＡＳＩＬ−Ｃの安全目標とされる。また、「車両速度が１５ｋｍ／ｈ以下で、ドア開閉スイッチがＯＮされたときに、ドアを開ける」の機能不全がハザードを引き起こすため、この機能にＡＳＩＬ−Ｃへの対応が要求される。ＡＳＩＬ−Ｃ対応が要求される機能のソフトウェア（Ｄ入力部１２，Ｄ演算部１３，Ｄ出力部１４）は、制御フローモニタリング等の付随機能と要求事項に対してインスペクションによるインフォーマルな整合性検証等が要求されるため、再開発が必要となる。
【００１０】
この場合のソフトウェアは、既に開発していた「車両速度が１５ｋｍ／ｈ以下で、ドア開閉スイッチがＯＮされたときに、ドアを開ける」と基盤ソフトウェア（ＢＳＷ１０，ＲＴＥ１１）とを破棄して再開発を実施するため、差分開発に比べて開発コストが増加してしまう。すなわち、Ｄ入力部１２，Ｄ演算部１３，Ｄ出力部１４が機能安全規格に応じて再開発されることにより、それらの処理を管理するＢＳＷ１０，ＲＴＥ１１も再開発する必要が生じる。また、再開発により品質低下のリスクも発生する。
【００１１】
そこで、本発明は、既存のソフトウェアを再利用しつつ新たな機能安全要求にも対応可能な車両制御装置、及び、その車両制御装置を構成するのに利用可能なソフトウェア部品を提供することを目的としてなされた。
【課題を解決するための手段】
【００１２】
前記目的を達するためになされた本発明の車両制御装置は、入力に対して、機能安全規格に対応した出力を行う第１制御手段と、前記第１制御手段のソフトウェアを管理し、前記機能安全規格に対応した第１プラットホームと、前記入力に対して、前記機能安全規格に非対応の出力を行う第２制御手段と、前記第２制御手段のソフトウェアを管理し、前記機能安全規格に非対応の第２プラットホームと、前記第１制御手段の出力と前記第２制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、を備え、前記第１プラットホームと前記第２プラットホームとが、少なくとも、前記第１プラットホームによる前記第１制御手段のソフトウェアの管理と前記第２プラットホームによる前記第２制御手段のソフトウェアの管理とに関して独立していることを特徴としている。
【００１３】
このように構成された本発明の車両制御装置では、第１制御手段は、そのソフトウェアが機能安全規格に対応した第１プラットホームに管理されており、入力に対して機能安全規格に対応した出力を行う。一方、第２制御手段は、そのソフトウェアが機能安全規格に非対応の第２プラットホームに管理されており、入力に対して機能安全規格に非対応の出力を行う。そして、比較結合手段は、前記第１制御手段の出力と前記第２制御手段の出力とを比較結合して制御対象に出力する。
【００１４】
ここで、第１プラットホーム，第２プラットホームは、少なくとも、第１プラットホームによる第１制御手段のソフトウェアの管理と第２プラットホームによる第２制御手段のソフトウェアの管理とに関して独立している。このため、第２制御手段及び第２プラットホームに既存のソフトウェアを割り当て、第１制御手段及び第１プラットホームを新たに追加したとしても、その追加に応じて第２制御手段及び第２プラットホームを変更する必要がない。また、比較結合手段により第１制御手段の出力と第２制御手段の出力とを適切に比較結合すれば、全体として前記機能安全規格に対応した制御が可能となる。
【００１５】
従って、本発明では、既存のソフトウェアを有効に再利用しつつ、新たな機能安全要求にも対応することができる。更に、第１制御手段のソフトウェアを、機能安全規格に対応することが要求される機能に関連するもののみとすれば、当該ソフトウェアに係るプログラムを記憶するためのメモリ容量低減も可能となる。
【００１６】
なお、本発明において、前記第１制御手段，前記第１プラットホーム，前記第２制御手段，前記第２プラットホーム，及び前記比較結合手段のいずれか１つ（但し、前記第２制御手段単独を除く）が、またはいずれか複数が協働することにより、前記第２制御手段に係る機能不全の発生を抑制してもよい。
【００１７】
また、本発明において、前記第１制御手段，前記第１プラットホーム，前記第２制御手段，前記第２プラットホーム，及び前記比較結合手段のいずれか１つ（但し、前記第２制御手段単独を除く）が、またはいずれか複数が協働することにより、前記第２制御手段に係る機能不全が発生した場合に前記制御対象への出力を安全状態に移行させてもよい。
【００１８】
また、その場合、前記第１制御手段のソフトウェアは、前記第２制御手段のソフトウェアに係るプログラムのうち、前記機能安全規格に対応することが要求される機能に関連するもののみを切り出して、前記機能安全規格に対応させて構成されてもよい。この場合、デコンポジションを活用し、第２制御手段のソフトウェアに係るプログラムのうちの前記機能安全規格に対応することが要求される機能に関連するもののみを切り出して前記機能安全規格に対応させたものが、第１制御手段のソフトウェアを構成するため、そのソフトウェアに係るプログラムを記憶するためのメモリ容量を低減することができる。
【００１９】
すなわち、機能安全規格への対応が要求される機能は、付随機能の追加を実施するため、プログラムサイズが大きくなり、機能安全規格への対応が要求されない制御装置に移植して再利用した場合、プログラムメモリが大きい高価なマイクロコンピュータ（以下マイコンという）を利用しなければならなくなるが、本発明を前記のように構成した場合はプログラムメモリの小さい安価なマイコンを利用することができる。
【００２０】
また、本発明において、前記入力を前記第１制御手段または前記第１プラットホームを介して前記第２制御手段または前記第２プラットホームに入力する処理、前記第１制御手段及び前記第２制御手段に係る処理、前記比較結合手段に係る処理、の順で、処理が実行されてもよい。また、本発明において、前記第２制御手段に係る処理の一部または全部が、前記比較結合手段に係る処理以外の処理と前記比較結合手段に係る処理との間に実行されてもよい。
【００２１】
また、本発明において、前記第１制御手段のソフトウェアに係るプログラム（すなわちＡＳＩＬ部）を取り外し可能に構成されてもよい。その場合、ＡＳＩＬ部を新たな機能安全要求に対応したものとするのが一層容易となる。
【００２２】
また、本発明において、前記第１制御手段のソフトウェアに係るプログラムと前記第２制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、前記メモリは前記配置ブロック毎に配置アドレスを設定可能であってもよい。
【００２３】
また、本発明の車両制御装置は、複数のシーケンスモニタの有効範囲を前記各シーケンスモニタ間でオーバーラップさせたことを特徴とするものであってもよい。その場合、複数のシーケンスモニタ間で有効範囲がオーバーラップしているので、当該複数のシーケンスモニタによるチェックをもれなく行うことができる。
【００２４】
また、本発明の車両制御装置は、入力に対して、機能安全規格に対応した出力を行う第１制御手段と、前記第１制御手段のソフトウェアを管理し、前記機能安全規格に対応した第１プラットホームと、前記入力に対して、前記機能安全規格に非対応の出力を行う第２制御手段と、前記第２制御手段のソフトウェアを管理し、前記機能安全規格に非対応の第２プラットホームと、前記第１制御手段の出力と前記第２制御手段の出力とを比較結合して制御対象に出力する比較結合手段と、を備え、前記第２制御手段のソフトウェアとして既存のソフトウェアを、第１制御手段のソフトウェアとして新規開発のソフトウェアを、それぞれ割り当てたことを特徴とするものであってもよい。この場合も、既存のソフトウェアを再利用することにより、開発コストを低減することができる。
【００２５】
そして、その場合、前記第１制御手段のソフトウェアに係るプログラム（すなわちＡＳＩＬ部）を取り外し可能に構成されてもよい。その場合、ＡＳＩＬ部を新たな機能安全規格に対応したものとするのが一層容易となる。
【００２６】
そして、その場合、前記第１制御手段のソフトウェアに係るプログラムと前記第２制御手段のソフトウェアに係るプログラムとを異なる配置ブロックに記憶したメモリを備え、前記メモリは前記配置ブロック毎に前記プログラムを取り外し可能であってもよい。その場合、前記第１制御手段のソフトウェアに係るプログラムの取り外しが、配置ブロックの取り外し（削除等）によって一層容易に実行できる。
【００２７】
また、その場合、前記第１制御手段のソフトウェアに係るプログラムと前記第２制御手段のソフトウェアに係るプログラムとが別ファイルで管理され、各々のファイルが取り外し可能とされていてもよい。その場合、前記第１制御手段のソフトウェアに係るプログラムの取り外しが、ファイルの取り外し（削除等）によって一層容易に実行できる。
【００２９】
また、前記目的を達するためになされた本発明のソフトウェア部品は、入力に対して、機能安全規格に対応した出力を行う第１制御手段のソフトウェアに係るプログラムと、前記入力に対して、前記機能安全規格に非対応の出力を行う第２制御手段のソフトウェアに係るプログラムとに分けて管理することを特徴としている。その管理方法として、各プログラムの変数またはコンポーネントの少なくともいずれか一方をそれぞれ記憶した別ファイルでの管理を挙げている。このように構成されたソフトウェア部品では、第２制御手段のソフトウェアに係るプログラム（例えばＱＭ部）を再利用することが容易になる。
【００３０】
また、前記目的達するためになされた本発明のソフトウェア部品は、機能安全規格に対応したプラットホームのソフトウェアによって管理され、前記機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアとは別に取り付け可能に構成されたことを特徴とするものであってもよい。このように構成されたソフトウェア部品を利用すれば、機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアに当該ソフトウェアとは別のソフトウェアとして取り付けることによって、既存のソフトウェアを有効に再利用しつつ、新たな機能安全要求にも対応することができる。
【００３７】
そして、前記目的達するためになされた本発明の車両制御装置は、前記いずれかのソフトウェア部品を備えたことを特徴とするものであってもよい。
また、前記目的達するためになされた本発明のソフトウェア部品は、機能安全規格に対応したソフトウェアに係るプログラムを、前記機能安全規格に対応したプラットホームのソフトウェアに対して取り付け可能に構成されたことを特徴とするものであってもよい。このように構成されたソフトウェア部品を利用すれば、機能安全規格に対応したソフトウェアに係るプログラムを、前記プラットホームのソフトウェアに対して取り付けることによって、既存のソフトウェアを有効に再利用しつつ、新たな機能安全要求にも対応することができる。
【００４２】
そして、前記目的達するためになされた本発明の車両制御装置は、前記ソフトウェア部品を備えたことを特徴とするものであってもよい。
また、前記目的達するためになされた本発明のソフトウェア部品は、デイジーチェーンの接続元と接続先とを設定することで、機能安全規格に対応したソフトウェアに係るプログラムに接続可能なことを特徴とするものであってもよい。
【００４３】
そして、前記車両制御装置は、前記接続先を設定することで、前記ソフトウェア部品との接続を可能とするものであってもよい。
【図面の簡単な説明】
【００４４】
【図１】本発明を適用可能な制御系の構成を表すブロック図である。
【図２】その制御系に適用した実施形態の電動ドアＥＣＵを表すブロック図である。
【図３】その電動ドアＥＣＵと開閉ドアＥＣＵ、車内ライトＥＣＵにおける処理を表すフローチャートである。
【図４】その処理におけるＢＳＷ間の送信処理を表すフローチャートである。
【図５】前記処理における機能安全対応処理を表すフローチャートである。
【図６】前記処理における機能安全非対応処理を表すフローチャートである。
【図７】前記処理における比較結合処置の処理を表すフローチャートである。
【図８】前記処理における機能安全対応を要しない処理を表すフローチャートである。
【図９】前記電動ドアＥＣＵにおけるデータ配置を表す模式図である。
【図１０】前記電動ドアＥＣＵの診断コンポーネントを表すブロック図である。
【図１１】当該診断コンポーネントの要部を詳細に表すブロック図である。
【図１２】前記電動ドアＥＣＵにおけるコンポーネント配置を表す模式図である。
【図１３】前記電動ドアＥＣＵにおけるシーケンス＆時間モニタの一例を表す説明図である。
【図１４】前記電動ドアＥＣＵにおける読み書き＆演算モニタの一例を表す説明図である。
【図１５】前記制御系に適用した比較例の電動ドアＥＣＵを表すブロック図である。
【発明を実施するための形態】
【００４５】
［車両制御装置の全体構成］
次に、本発明の実施形態を図面と共に説明する。なお、本実施形態の車両制御装置としての電動ドアＥＣＵ１００も、前述の図１に示した制御系に電動ドアＥＣＵ１の代わりに用いられる。図２は、電動ドアＥＣＵ１００のソフトウェア構成を模式的に表すブロック図である。なお、電動ドアＥＣＵ１００は、ドア開閉スイッチの操作時に車内ライトＬをＬＴＩＭＥ時間点灯し、ドア開閉スイッチが操作されかつ車速が１５ｋｍ／ｈ未満のときにドアＤを開く処理を実行する制御を、ＡＳＩＬ−Ｃに従って実行する。
【００４６】
図２に示すように、電動ドアＥＣＵ１００は、ハードウェア資源として、制御に必要な各種演算を行う演算部１００Ａと、前述の開閉スイッチＥＣＵ３，車速計測ＥＣＵ４から入力されるドア開閉スイッチの操作状態と車速とが入力される入力部１００Ｂと、ドアＤや車内ライトＬに制御信号を出力する出力部１００Ｃとを備えている。次に、演算部１００Ａのソフトウェア構成ついて説明する。
【００４７】
演算部１００Ａも、前述の演算部１Ａと同様の、ＢＳＷ１０，ＲＴＥ１１，Ｄ入力部１２，Ｄ演算部１３，Ｄ出力部１４，Ｌ入力部１５，Ｌ演算部１６，Ｌ出力部１７を備えている。そして、演算部１００Ａは、機能安全規格としてのＡＳＩＬ−Ｃに対応したＤ入力部１１２，Ｄ演算部１１３，Ｄ出力部１１４を、ＡＳＩＬ−Ｃに非対応のＤ入力部１２，Ｄ演算部１３，Ｄ出力部１４と並列に備えている。また、ＢＳＷ１０やＲＴＥ１１はこれらのＤ入力部１１２，Ｄ演算部１１３，Ｄ出力部１１４の管理に対応していない。そこで、演算部１００Ａは、Ｄ入力部１１２，Ｄ演算部１１３，Ｄ出力部１１４をＢＳＷ１０，ＲＴＥ１１とは独立して管理するＢＳＷ１１０，ＲＴＥ１１１も、ＢＳＷ１０，ＲＴＥ１１と並列に備えている。
【００４８】
また、Ｄ入力部１１２，Ｄ演算部１１３，Ｄ出力部１１４は、Ｄ入力部１２，Ｄ演算部１３，Ｄ出力部１４のうちＡＳＩＬ−Ｃに対応することが要求される部分だけを切り出して、ＡＳＩＬ−Ｃに対応させたものである。従って、図２に矢印で示したように、Ｄ入力部１１２，Ｄ演算部１１３，Ｄ出力部１１４に係るメモリ容量を低減することができ、それらを管理するＢＳＷ１１０，ＲＴＥ１１１に係るメモリ容量も低減することができる。
【００４９】
なお、前記構成において、ＢＳＷ１０，ＲＴＥ１１が第２プラットホームに、Ｄ入力部１２，Ｄ演算部１３，Ｄ出力部１４，Ｌ入力部１５，Ｌ演算部１６，Ｌ出力部１７が第２制御手段に、Ｄ入力部１１２，Ｄ演算部１１３，Ｄ出力部１１４が第１制御手段に、ＢＳＷ１１０，ＲＴＥ１１１が第１プラットホームに、ＲＴＥ１１１が比較結合手段に、それぞれ対応する。
【００５０】
［車両制御装置における処理］
図３のＳ１〜Ｓ９は、電動ドアＥＣＵ１００において所定時間毎に繰り返し実行される処理を表すフローチャートである。図３に示すように、この処理で、電動ドアＥＣＵ１００は、先ずＳ１にて（Ｓはステップを表す：以下同様）、機能安全規格に対応したＢＳＷ１１０から機能安全規格に非対応のＢＳＷ１０への送信が実行される。図４は、その送信処理を詳細に表すフローチャートである。なお、この処理は、主としてＢＳＷ１１０によって実行される。
【００５１】
図４に示すように、この送信処理では、先ず、Ｓ１１にて、入力部１００Ｂが前述の開閉スイッチＥＣＵ３（図１参照）等から受信した変数ＳＲＥＱ２，ＳＳＷ１，ＳＳＷ１Ｓが、当該入力部１００Ｂから受信される。なお、変数ＳＲＥＱ２は、ドアＤに対する何らかの要求有無を表す変数で、ＳＳＷ１はドア開閉スイッチのＯＮ／ＯＦＦ状態を表す変数で、ＳＳＷ１Ｓは（ドア開／ドア閉）を表す変数である。続くＳ１３では、前記ＳＲＥＱ２，ＳＳＷ１，ＳＳＷ１Ｓが、ＲＥＱ２，ＳＷ１，ＳＷ１Ｓとして、ＢＳＷ１１０からＢＳＷ１０へ送信され、処理は図３のＳ３へ移行する。
【００５２】
図３へ戻って、Ｓ３では、機能安全規格に対応した、後述の比較結合処置（Ｓ７）以外の処理が実行される。図５は、その処理を詳細に表すフローチャートである。なお、この処理は、主としてＤ演算部１１３によって実行される。
【００５３】
図５に示すように、この処理では、先ず、Ｓ３１にて、変数ＳＲＥＱ２が要求なしにセットされ、続くＳ３３にて、変数ＳＳＷ１がＯＮとなっているか否か、すなわち、前記ドア開閉スイッチがＯＮされているか否かが判断される。ＳＳＷ１＝ＯＦＦの場合は（Ｓ３３：Ｎ）、車両としての処理がそのまま一旦終了し（図３参照）、ＳＳＷ１＝ＯＮの場合は（Ｓ３３：Ｙ）、処理はＳ３５へ移行する。Ｓ３５では、変数ＳＲＥＱ２が要求ありにセットされ、Ｓ３７にて、変数ＳＳＷ１Ｓの値が変数ＳＯＰＮ２Ｒに代入される。
【００５４】
続くＳ３９では、車速（ＳＰＥＥＤ）が１５ｋｍ／ｈ未満であるか否かが判断され、ＳＰＥＥＤ＜１５ｋｍ／ｈの場合はそのまま（Ｓ３９：Ｙ）、ＳＰＥＥＤ≧１５ｋｍ／ｈの場合は（Ｓ３９：Ｎ）、Ｓ４１にて変数ＳＲＥＱ２が要求なしにセットされた後、処理は図３のＳ５へ移行する。
【００５５】
図３へ戻って、Ｓ５では、機能安全規格への対応を要求された機能を含む従来のソフトウェア処理が実行される。図６は、その処理を詳細に表すフローチャートである。なお、この処理は、主としてＤ演算部１３によって実行される。
【００５６】
図６に示すように、この処理では、先ず、Ｓ５１にて、変数ＲＥＱ２が要求なしにセットされ、続くＳ５３にて、変数ＳＷ１がＯＮとなっているか否か、すなわち、前記ドア開閉スイッチがＯＮされているか否かが判断される。ＳＷ１＝ＯＦＦの場合は（Ｓ５３：Ｎ）、車両としての処理がそのまま一旦終了し（図３参照）、ＳＷ１＝ＯＮの場合は（Ｓ５３：Ｙ）、処理はＳ５５へ移行する。Ｓ５５では、変数ＲＥＱ２が要求ありにセットされ、Ｓ５７にて、変数ＳＷ１ＳがＯＮであるか否かが判断される。
【００５７】
ＳＷ１Ｓ＝ＯＮの場合は（Ｓ５７：Ｙ）、Ｓ５８にて変数ＯＰＮ２Ｒが開にセットされ、続くＳ５９では、車速（ＳＰＥＥＤ）が１５ｋｍ／ｈ未満であるか否かが判断される。そして、ＳＰＥＥＤ＜１５ｋｍ／ｈの場合はそのまま（Ｓ５９：Ｙ）、ＳＰＥＥＤ≧１５ｋｍ／ｈの場合は（Ｓ５９：Ｎ）、Ｓ６１にて変数ＲＥＱ２が要求なしにセットされた後、処理は図３のＳ７へ移行する。また、Ｓ５７にてＳＷ１Ｓ≠ＯＮと判断された場合は（Ｓ５７：Ｎ）、Ｓ６３にて変数ＯＰＥＮ２Ｒが閉にセットされて、処理は図３のＳ７へ移行する。
【００５８】
図３へ戻って、Ｓ７では、機能安全規格に対応した比較結合処置の処理が実行される。図７はその処理を表すフローチャートである。なお、この処理は、主としてＲＴＥ１１１によって実行される。
【００５９】
図７に示すように、この処理では、先ず、Ｓ７１にて、変数ＳＲＥＱ２の値が変数Ａに、変数ＲＥＱ２の値が変数Ｂに、それぞれ代入される。続くＳ７３では、Ａ＝Ｂであるか否かが判断され、Ａ＝Ｂである場合は（Ｓ７３：Ｙ）、処理はＳ７５へ移行する。Ｓ７５では、変数ＳＯＰＮ２Ｒの値が変数Ａに、変数ＯＰＮ２Ｒの値が変数Ｂに、それぞれ代入される。続くＳ７７では、Ａ＝Ｂであるか否かが判断され、Ａ＝Ｂである場合は（Ｓ７７：Ｙ）、処理はＳ７９へ移行する。Ｓ７９では、変数ＳＲＥＱ２，ＳＯＰＮ２Ｒの値が出力部１００Ｃに送られ、処理は図３のＳ９へ移行する。
【００６０】
一方、Ｓ７３またはＳ７７にてＡ≠Ｂと判断された場合は（Ｓ７３：ＮまたはＳ７７：Ｎ）、Ｓ８１にてＳＲＥＱ２が要求なしにセットされて、処理は前述のＳ７９へ移行する。すなわち、ドアＤを開く制御はハザードとなり得るため、Ｄ演算部１３，１１３の演算結果が完全に一致しない場合（例えばＤ演算部１３の機能不全が生じた場合）は、出力を安全状態に移行させるのである。
【００６１】
図３へ戻って、Ｓ９では、機能安全規格への対応を要求された機能を含まない従来のソフトウェア処理が実行される。図８は、その処理を表すフローチャートである。なお、この処理は、主としてＬ演算部１６によって実行される。
【００６２】
図８に示すように、この処理では、先ず、Ｓ９１にて、ＬＴＩＭＥが１５秒に設定される。続くＳ９３では、Ｓ９１にて設定されたＬＴＩＭＥが出力部１００Ｃに送られ、処理は図３のＳ２１へ移行する。なお、図３のＳ２１以降の処理は、開閉ドアＥＣＵ５によって実行される。
【００６３】
図３に示すように、Ｓ２１では、前述のＳ７９にて送信された変数ＳＲＥＱ２，ＳＯＰＮ２Ｒの値が開閉ドアＥＣＵ５によって受信され、続くＳ２３にて、変数ＳＲＥＱ２がＯＮ（すなわち要求あり）にセットされているか否かが判断される。ＳＲＥＱ２≠ＯＮの場合は（Ｓ２３：Ｎ）、車両としての処理がそのまま一旦終了し、ＳＲＥＱ２＝ＯＮの場合は（Ｓ２３：Ｙ）、処理はＳ２５へ移行する。Ｓ２５では、変数ＳＯＰＮ２Ｒが開にセットされているか否かが判断される。ＳＯＰＮ２Ｒ＝開のときは（Ｓ２５：Ｙ）、Ｓ２６にてドアＤを開く制御がなされた後、ＳＯＰＮ２Ｒ≠開のときは（Ｓ２５：Ｎ）、Ｓ２７にてドアＤを閉じる制御がなされた後、それぞれ処理はＳ２８へ移行する。
【００６４】
Ｓ２８では、前述のＳ９３にて送信されたＬＴＩＭＥの値が車内ライトＥＣＵ５Ｌによって受信され、続くＳ２９にて、車内ライトＬをＬＴＩＭＥ時間だけＯＮ（点灯）する制御が実行されて、車両としての処理が一旦終了する。このように、本実施形態では、既存のソフトウェアを有効に再利用しつつ、全体として新たな機能安全要求にも対応することができる。しかも、本実施形態では、新たな機能安全規格対応して追加した構成は、その機能安全規格への対応が要求された機能に係るプログラムのうちの、前記機能安全規格に対応することが要求される機能に関するもののみを切り出して前記機能安全規格に対応させたものであるので、当該プログラムを記憶するためのメモリ容量を低減することもできる。また、ＢＳＷ１０〜Ｌ出力部１７として既存のソフトウェアを再利用しているので、電動ドアＥＣＵ１００の開発コストも低減することができる。
【００６５】
すなわち、本実施形態では、Ｄ入力部１２，Ｄ演算部１３，Ｄ出力部１４（以下ＡＳＩＬ部という）を付随機能と付随機能以外に分離し、付随機能を取り付け可能とすることで、付随機能を再利用している。
【００６６】
また、ＲＴＥ１１１，ＢＳＷ１１０に対するソフトウェアの接続順序や、当該接続されたソフトウェアの実行順序は可変であってもよい。更に、Ｄ入力部１１２、Ｄ演算部１１３、Ｄ出力部１１４は、基盤ソフトウェア以外として次に列挙するような付随機能を有している。
ａ）ソフトウェアのプログラムの実行順序を監視するシーケンスモニタとしての機能。
ｂ）ソフトウェアのプログラムの実行時間を監視する時間モニタとしての機能。
ｃ）ソフトウェアのデータの読み込みと書き出しを監視する読み書きモニタとしての機能。
ｄ）ソフトウェアのデータの演算を監視する演算モニタとしての機能。
【００６７】
そして、それらの機能を実現するための取り付け手法としては、次に列挙するようなものが考えられる。
ａ）プログラムの接続情報と順序識別子の可変設定を可能とするシーケンスモニタを構成する。
ｂ）プログラムの実行時間の可変設定を可能とする時間モニタを構成する。
ｃ）監視するデータの指定を可変とする読み書きモニタを構成する。
ｄ）監視するデータ（演算への入力データ、演算の出力データ）の指定を可変とする演算モニタを構成する。
【００６８】
また、ＲＴＥ１１１，ＢＳＷ１１０は、基盤ソフトウェアとして次に列挙するような付随機能を有している。
ｅ）通信接続を監視するネットワーク接続モニタとしての機能。
ｆ）通信プログラムの実行時間を監視するネットワーク時間モニタとしての機能。
ｇ）通信データの読み込みと書き出しを監視するネットワーク読み書きモニタとしての機能。
【００６９】
そして、それらの機能を実現するための取り付け手法としては、次に列挙するようなものが考えられる。
ｅ）通信の接続情報の可変設定を可能とするネットワーク接続モニタを構成する。
ｆ）通信プログラムの実行時間の可変設定を可能とするネットワーク時間モニタを構成する。
ｇ）通信データの指定を可変とするネットワーク読み書きモニタを構成する。
【００７０】
また、本実施形態では、機能不全の検出をコンピュータの基本動作である以下の３点に絞ることで、付随機能のプログラムサイズを抑えることが可能となる。
（１）プログラム順序に従ったステップ実行（プログラム実行）：シーケンスモニタ、時間モニタ、ネットワーク接続モニタ、ネットワーク時間モニタ
（２）データの読み出し・書き出し（データ保存）：読み書きモニタ
（３）データの演算（データ演算）：演算モニタ
以下、それらの機能実現に関する構成について説明する。図９に示すように、電動ドアＥＣＵ１００では、既存のＢＳＷ１０〜Ｌ出力部１７に係るプログラムの変数を記憶したブロックＤ１，Ｄ２，Ｄ３と、ＡＳＩＬ−Ｃに対応したＢＳＷ１１０〜Ｄ出力部１１４に係るプログラムの変数を記憶したブロックＤ４，Ｄ５，Ｄ６，Ｄ７と、を異なる配置ブロックに記憶したメモリを備え、前記メモリは前記配置ブロック毎に前記変数を取り外し可能に構成されている。このため、ＡＳＩＬ−Ｃに対応したプログラムの取り外しが、配置ブロックの取り外し（削除等）によって一層容易に実行できる。従って、新たな機能安全要求に対応した電動ドアＥＣＵ１００も容易に開発することができる。なお、配置ブロックの代わりに、ファイルが取り外し可能とされていてもよい。その場合、ＡＳＩＬ−Ｃに対応したプログラムの取り外しが、ファイルの取り外し（削除等）によって一層容易に実行できる。
【００７１】
次に、図１０は、電動ドアＥＣＵ１００の診断コンポーネントを表すブロック図である。図１０に示すように、この診断コンポーネントは、互いに連接された制御コンポーネント診断機能部２１０及び制御コンポーネント２２０と、制御コンポーネント２２０から演算すべきデータを受信して演算結果を制御コンポーネント２２０へ返す演算コンポーネント２３０と、制御コンポーネント２２０への外部からのデータの入出力に使用される入出力コンポーネント２４０と、制御コンポーネント２２０がメモリとして使用するメモリコンポーネント２５０とを備えている。
【００７２】
また、制御コンポーネント診断機能部２１０は、演算コンポーネント２３０に入力されたデータとその演算結果とを入力されて診断を行う演算部診断部２１４と、制御コンポーネント２２０に設けられ第１Ｆｕｎ２２１，第２Ｆｕｎ２２２，第３Ｆｕｎ２２３の出力を入力されて制御コンポーネント２２０の診断を行う制御部診断部２１５と、メモリコンポーネント２５０に入出力されるデータを入力されてメモリコンポーネント２５０の診断を行うメモリ部診断部２１６とを備えている。なお、第１Ｆｕｎ２２１〜第３Ｆｕｎ２２３は、順次実行されることにより、機能が所定の実行順序で、かつ、所定の実行時間実行されているかを検出するためのシーケンスモニタである。
【００７３】
そして、図１１に示すように、第１Ｆｕｎ２２１〜第３Ｆｕｎ２２３では、モニタ範囲が矢印Ａで示すようにオーバーラップしているので、チェックをもれなく行うことができる。なお、シーケンスモニタの有効範囲とネットワーク接続の有効範囲とがオーバーラップしてもよく、その場合も、シーケンスモニタによるチェックをもれなく行うことができる。
【００７４】
また、このような各種コンポーネントＣ１，Ｃ２，Ｃ３，…も、図１２に例示するように、メモリの異なる配置ブロックに記憶され、そのメモリは前記配置ブロック毎に前記コンポーネントＣを取り外し可能に構成されている。このため、ＡＳＩＬ−Ｃに対応したプログラムの取り外しが、配置ブロックの取り外し（削除等）によって一層容易に実行できる。従って、新たな機能安全規格に対応した電動ドアＥＣＵ１００も容易に開発することができる。なお、配置ブロックの代わりに、ファイルが取り外し可能とされていてもよい。その場合、ＡＳＩＬ−Ｃに対応したコンポーネントの取り外しが、ファイルの取り外し（削除等）によって一層容易に実行できる。
【００７５】
また、参考のため、電動ドアＥＣＵ１００のソフトウェアに係るプログラムリストを例示する。図１３（Ａ）は、シーケンス＆時間モニタの関数定義を例示しており、図１３（Ｂ）は、シーケンス＆時間モニタの使用箇所を例示している。また、図１４（Ａ）は、読み書き＆演算モニタの関数定義を例示しており、図１４（Ｂ）は、読み書き＆演算モニタの使用箇所を例示している。
【００７６】
なお、本発明は前記実施形態に何ら限定されるものではなく、本発明の要旨を逸脱しない範囲で種々の形態で実施することができる。例えば、電動ドアＥＣＵ１００は、車内ライトＬの制御を行わず、ドアＤを開く制御のみを実行するものであってもよく、その場合にも前述のような作用・効果が発揮される。
【符号の説明】
【００７７】
１，１００…電動ドアＥＣＵ    １Ａ，１００Ａ…演算部    １Ｂ，１００Ｂ…入力部
１Ｃ，１００Ｃ…出力部        １０，１１０…ＢＳＷ      １１，１１１…ＲＴＥ
１２，１１２…Ｄ入力部        １３，１１３…Ｄ演算部    １４，１１４…Ｄ出力部
１５…Ｌ入力部                １６…Ｌ演算部            １７…Ｌ出力部
２１０…制御コンポーネント診断機能部          ２１４…演算部診断部
２１５…制御部診断部    ２１６…メモリ部診断部    ２２０…制御コンポーネント
２２１…第１Ｆｕｎ      ２２２…第２Ｆｕｎ        ２２３…第３Ｆｕｎ
２３０…演算コンポーネント                    ２４０…入出力コンポーネント
２５０…メモリコンポーネント    ＤＦＬ，ＤＦＲ，ＤＲＬ，ＤＲＲ…ドア
Ｌ…車内ライト
【図１】
0005549665.tif 000002
【図３】
0005549665.tif 000003
【図４】
0005549665.tif 000004
【図５】
0005549665.tif 000005
【図６】
0005549665.tif 000006
【図７】
0005549665.tif 000007
【図８】
0005549665.tif 000008
【図９】
0005549665.tif 000009
【図１２】
0005549665.tif 000010
【図１３】
0005549665.tif 000011
【図１４】
0005549665.tif 000012
【図２】
0005549665.tif 000013
【図１０】
0005549665.tif 000014
【図１１】
0005549665.tif 000015
【図１５】
0005549665.tif 000016