JPH03149337A - 自律分散型エンジン制御装置 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 【産業上の利用分野〕 本発明は、エンジンの回転速度や吸気流量などエンジン
運転状態を表わす各種情報の検出結果に基づいて燃料供
給量や点火時期などを制御する方式の自律分散型エンジ
ン制御装置に係り、特に自動車用ガソリンエンジンの燃
料供給量制御に好適な自律分散型エンジン制御装置に関
する。

〔従来の技術〕

各種の内燃機関のうち、特に自動車用ガソリンエンジン
では、厳しい排ガス規制のクリアと、充分なエンジン性
能の向上とが要求されるため、エンジンの吸気流量や回
転速度など、エンジンの運転状態を表わす各種のデータ
を逐次取り込み、これに基づいて所定の制御データを算
定し、この制御データにより、燃料供給量や点火時期な
どを最適な状態に制御する方式の制御装置が使用される
ようになってきており、その例を、例えば特開昭５フー
２４３３号や特開昭５９−１５３９３３号の各部報に見
ることが出来る。

そして、さらに、このようなシステムにおいて、各部の
処理に自律性を持たせるようにした、いわゆる自律分散
型のエンジン制御システムも提案されるようになり、そ
の例として、 自動車技術会　学術講演会前刷集８８１昭６１−５ｐ２
１フー２２０文献Ｎｏ、８８１０５５を挙げることがで
き、そこに記載のシステムでは、燃料制御用コントロー
ラ、点火制御用コントローラ、スロットル制御用コント
ローラ、大量データ処理用コントローラ、通信用コント
ローラ、センサ用コントローラ、それにエンジンスピー
ド用コントローラなど、計７種のコントローラが通信路
に載せられている。

〔発明が解決しようとする課題〕

上記従来技術は、複数のコントローラを使用する上での
フェイルセイフについて配慮がされておらず、複数のコ
ントローラの内の１個にでも異常が発生すると、正常な
エンジン制御の維持が困難になってしまうという問題が
あった。

特に、通信用コントローラが故障した場合には、全ての
項目の制御に支障を生じてしまうことになる。

また、上記従来技術では、エンジンシステムの仕様変更
について配慮がされておらず、コントローラの追加や特
性変更に際しては、それぞれの内部でのプログラムやデ
ータの再マツチングが必要になるという問題があった。

本発明の目的は、フェイルセイフが充分で高い信頼性が
保て、かつ、システム再編が容易で簡単に仕様変更に対
応出来るようにした自律分散型エンジン制御装置を提供
することにある。

〔課題を解決するための手段〕

上記目的を達成するため、本発明は、自律分散機能を備
えたセンサやアクチュエータなどのモジュールにバック
アップ機能を付与すると共に、各自律分散モジュールを
共通のデータバスに並べた上で、このデータバスに所定
の管理装置を任意に接続し得るようにしたものである。

〔作用〕

各自律分散モジュールに付与されているバックアップ機
能により、そのモジュールがたとえ故障しても、このバ
ックアップ機能により所定の機能が維持されるため、他
のモジュールの動作に悪影響が与えられることはなく、
エンジン制御には必要なフェイルセイフが保たれ、かつ
、必要に応じてデータバスに管理装置を接続して各モジ
ュールごとにプログラム・データの仁シャライズが可能
になるので、システム再編にも柔軟に対応できる。

〔実施例〕

以下、本発明による自律分散型エンジン制御装置につい
て、図示の実施例により詳細に説明する。

第１図は、本発明の一実施例で、図において、１．２．
３はアトム、４はシステム管理装置、そして５はデータ
バスである。

ここでは、エンジン制御に必要な各種のセンサやアクチ
ュエータがコンピュータを搭載したモジュールとして構
成され、インテリジェント化されており、これらをアト
ムと呼んでいる。従って、アトム１はエンジンの冷却水
温度検出用の水温センサモジュール、アトム２はエンジ
ンの吸気流量計測用のホットワイヤセンサモジュール、
そしてアトム３は燃料噴射用のインジェクタモジュール
であり、これらは共通のデータバス５に並列に接続され
、相互に必要なデータの授受を行ってエンジンを制御し
ている。

システム管理装置（Ｓｙｓｔｅｍ−Ａｄｍｉｎｉｓｔｌ
ａｔｏｒ）　４は、図示してないが、ソケット、プラグ
など所定の接続器具によりデータバス５に任意に接続、
取外し可能に構成してあり、通常は自動車の出荷元の工
場、自動車ディーラなどに常備しである。そして、アト
ｌ、の交換や制御システムの組み替え（再編）が必要に
なったとき、データバス５に接続されるようになってい
る。

第２図は各アトムに組み込まれているコンピュータ・モ
ジュール２０の一実施例で、デジタル演算処理を行うＣ
ＰＵ（セントラル・プロセッシング・ユニット）２１、
各種センサなどの外部デバイスからの信号の取り込みや
、燃料噴射弁などのアクチュエータの駆動を行うＩｌｏ
（入出力回路）２２、共通回線となるデータバス５を介
してデータの授受を行う通信回路（Ｃｏｍｉｎｕｃａｔ
ｉｏｎ−ｉｃ）　２３、プログラムやデータを格納する
Ｅ”ＰＲＯＭ２４、ＰＲＯＭ２５、それにＣＰＵ２１に
異常が発生したときに制御を代行するバックアップ回路
２６とで構成されている。

そして、２種のメモりＥ”ＰＲＯＭ２４、ＰＲＯＭ２５
の内、Ｅ”ＰＲＯＭ２４には、システム−の組み替え時
に変更を要するデータやサブルーチンが格納されるよう
になっており、必要に応じてシステム管理装置４からの
指示により、内容が書換えられるようになっている。

　　次に、各アトムのプログラム構成について説明する
と、これらは第３図に示すようになっており、システム
の組み替えに際しても変更を必要としないプログラム（
ＯＳなど）やデータについてはｓｌａｉｎ−ｐｒｏｇｒ
ａｍ″に格納し、その他の変更を要するデータ、プログ
ラムについては、ｊｓｕｂｒｏｔｉｎｅ１〜３”とｄａ
ｔａ　１〜３”に格納しである。そして、これらの内、
”ｍａｉｎ−ｐｒｏｇｒａｍ”は第２図のＰＲＯＭ２５
に設定され、ｓｕｂｒｏｔｉｍｅ　１〜３″とｄａｔａ
　１〜３”はＥ”ＰＲＯＭ２４に書き込まれる。

一方、システム管理装置４がもつ、各アトムの組合せに
よるプログラム構成は第４図に示すようになっており、
プログラム名やデータ名で十記号が付されているものは
、その組合せで必要とされるものを、そして−記号が付
いているものは、その組合せでは不要なものをそれぞれ
表わしている。

従って、例えばアトムＩＮＧ（点火系）とＴＨＳ（水温
センサ）の組合せでは、”ｓｕｂｒｏｔｉｎｅ　Ｉ　１
”が必要で、ｓｕｂｒｏｔｉｎｅ　Ｉ　２”は不要なの
で削除されるものであることを表わす。

そこで、システム管理装置４は、この第４図の構成表を
基にして、システム再編時に各アトムのプログラムの最
適化を行うのである。

第５図は共通回線（データバス５）上でのデータフォー
マット５０を示したもので、まず、先頭部−フー には、以下に続く信号が情報であることを示すトークン
５１があり、これに続いてデータ認識用のｄａｔａ−ｉ
ｄ″５２と、同種のデータを区別するためのｔｙｐｅ″
５３とが続き、その後に本来のデータｄａｔａ”５４が
続くのである。ここで、各アトムは、ｔｙｐｅ″５３を
見て、以下のデータが自分のところで必要とするもので
あるか否かを判断する。

一方、各アトムから共通回線にデータを送出する際には
、信号をみていて、トークン５１が通過したあとの空い
ているところで送信するようにしてやればよい。

なお、他の方法として、データの退出タイミングを基本
同期周期の整数倍にとり、各々のデータ、を入れ子にし
て伝送するようにしてもよい。

第６図はシステム管理装置４が持っているアトム組合せ
テーブルを示したもので、このテーブルにはｍａｉｎ”
とｒｅｇｉｓｔｅｒ”とがあり、−ａｉｎ”テーブルに
は共通回線に接続され得る、全てのアトムについて記述
され、他方、”ｒｅｇｉｓｔｅｒ”テープルには、各々
のシステムに接続されているアトムが記録されている。

そこで、システム管理装置４は、自動車ディーラーなど
において、共通回線（データバス５）に接続されたとき
、そのシステムでは、そこに接続されているアトムが既
に仁シャライズ済みか否か、もしくは追加のアトムがあ
るか否かを、このアトム組合せテーブルをみることによ
り知ることができる。

第７図は、同じくシステム管理装置４が持つ、データテ
ーブルを示したもので、このテーブルには、エンジン制
御に必要な全てのデータｄａｔａ−ｉｄ”と、同じく必
要な単位とが記述されており、これらは、前述の第４図
のプログラムの組合せを用いて、プログラムの組合せを
行ったときのデータの検証に使用される。

次に、この実施例におけるシステム全体としての仁シャ
ライズ処理について、第８図により説明する。

この第８図の処理８０１は、システムの電源立ち上げ時
に開始され、まず、システムが構築済みか否かを判断す
る（ステップ８０２）。なお、このときの判断方法とし
ては、自動車ディーラなどでシステムの構築を行った際
、Ｅ”ＦＲＯＭ２４の所定番地にフラグがセットされる
ようにし、これを各アトムが立ち上げ時にチェックする
ようなプログラムをブーストすればよく、具体的に言え
ば、第６図のテーブルをチェックすればよい。

そして、まず、システムが構築されていなかったときに
は、続いてシステム管理装置がデータバスに接続されて
いるか否かが判断され（ステップ８０３）、接続されて
いなかったときには、それを要求する処理（ステップ８
０５）が実行される。

なお、このシステム管理装置の接続要求は、表示用のア
トムを設置しておき、適用な表示（視覚的、聴覚的）が
自動車の運転席でなされるようにすればよい。一方、シ
ステム管理装置の接続有りと判断されたら、ここで初め
てシステムの仁シャライズを行うのである（ステップ８
０６）。

一方、ステップ８０２でシステム構築済みと判断された
ときには、続いて追加アトムがあるか否かが調べられ（
ステップ８０４）、追加が無ければ、もう仁シャライズ
は完了しているのであるから、ここで処理を終了するが
、追加アトムがあったときには、ステップ８０３に戻り
、ステップ８０５かステップ８０６のいずれかの処理を
繰り返すのである。なお、このときの追加アトムの有無
も第６図のテーブルを調べればよい。具体的に言えば、
追加されたアトムについては、それを表わすフラグは、
まだＥ”ＦＲＯＭ２４にセットされていないから、この
追加されたアトム自身が立ち上がり時に、その旨を表わ
す信号を共通回線に送出するようようにしておけばよい
。

次に、上記したステップ８０６におけるシステム仁シャ
ライ処理の詳細について、第９図により説明する。

まず、システム管理装置は、ステップ９１０で、上記し
たシステムの”ｓｙｓｔｅｍ−ｉｄ”が登録されている
か否かを調べる。これも、上記の場合と同様に、登録済
の場合には各アトムがシステム立上り１１一 時に、それぞれのｓｙｓｔｅｍ−ｉｄ”を共通回線に送
出するように構成しておけば良い。

ｓｙｓｔｅｍ−ｉｄ”が登録されていた場合には、ステ
ップ９０２で、システム管理装置内のｓｙｓｔｅｍ−ｉ
ｄテーブルを検索し、システムの構築状態を調べる。そ
して、ステップ９０３のｓｙｓｔｅｍ−ｉｄ要求処理を
行い、その後、ステップ９０４の処理を実行し、このと
きのシステム構築情報を３ｙｓｔｅｍ−ｉｄテーブルに
登録し、第６図のシステム・アドミニストレータ・テー
ブル （ｓｙｓｔｅｍ−ａｄｍｉｎｉｓｔｌａｔｏｒ　ｒｅｇ
ｉｓｔｅｒ　ｔａｂｌｅ）にシステム情報を登録する。

次に、ステップ９０３でのｓｙｓｔｅｍ−ｉｄ要求処理
について、第１０図により説明する。

まず、システム管理装置は、自らが持つシステム・アド
ミニストレータ・メイン・テーブル（ｓｙｓｔｅｍ−ａ
ｄＩＩＩｉｎｉｓｔｌａｔｏｒ　ｍａｉｎ　ｔａｂｌｅ
）を検索し、テーブル隘の順に各アトムをポーリングし
て応答の有無を確認する。そして応答有りの場合に登録
を実行する（ステップ１００４〜ステツブ１００５）。

次に、システム管理装置は、既に構築しであるシステム
に新規なアトムが存在するか否かを確認し、新規なアト
ムがあった場合には仁シャル・プログラムのロードを実
行する（ステップ１００６〜ステツプ１００９）。

このとき、ステップ１００８．１００９では、第４図の
プログラム組合せ表を参照し、必要なデータやプログラ
ムをリロードするようにする。

第１１図は、ステップ１００７の仁シャル・プログラム
・ロード処理の詳細を示したもので、まず、ステップ１
１０１では、目標とするアトムに仁シャル・プログラム
・ロード送信信号の送出を行う。

この送信信号を受信したアトムがスタンバイ状態にあれ
ば、これに応じて、ステップ１１０２の処理として受信
スタンバイ信号が返送され、続いてステップ１１０３で
シリアル受信機を受信状態にし、さらにステップ１１０
４でアドレス・データ・バスを開放する。

一方、上記した受信スタンバイ信号に応じて、システム
管理装置は対応するアトムに対して仁シャル・プログラ
ムの送出を行い（ステップ１１０６）、これを受信した
アトムがＥ”ＦＲＯＭ２４に書込み（ステップ１１０７
）、それが確認されたところで処理が終了するのである
（ステップ１１０８）。

従って、この実施例によれば、各アトム（自律分散モジ
ュール）にバックアップ機能が付与されているので、そ
のモジュールがたとえ故障しても、このバックアップ機
能により所定の機能が維持されるため、他のモジュール
の動作に悪影響が与えられることはなく、エンジン制御
には必要なフェイルセイフが保たれ、かつ、必要に応じ
てデータバスに管理装置を接続して各モジュールごとに
プログラム・データの仁シャライズが可能になるので、
システム再編にも柔軟に対応できる。

〔発明の効果〕

本発明によれば、自律分散モジュールにバックアップ機
能を付与したので、ユニットの異常に際してもエンジン
制御に重大な支障が発生する虞れがないので、信頼性を
損なうことなく、充分に自律分散方式の利点を活かすこ
とができ、システム変更などに柔軟に、しかも容易に対
応することができる。

また、本発明によれば、共通のデータバスが用いられて
いるため、モジュールの追加や変更が容易である。

さらに、本発明によれば、システム管理装置によりシス
テムごとのプログラム構成表やモジュール構築表の管理
が出来るので、プログラムメンテナンス、ハードウェア
構成メンテナンスも容易であるという効果がある。そし
て、このシステム管理装置は、自動車に常時備え付けて
おく必要がないから、ユーザから切り離してディーラの
管理下におくことができ、従って、車両搭載に伴うスペ
ース問題などからフリーになるという効果がある。

【図面の簡単な説明】

第１図は本発明による自律分散型エンジン制御装置の一
実施例を示す構成図、第２図は本発明によるコンピュー
タ・モジュールの一実施例を示すブロック構成図、第３
図及び第４図はプログラム構成図、第５図はデータ形式
の説明図、第６図及び第７図はテーブルの説明図、第８
図、第９図、第１１図二それに第１１図はそれぞれ動作
説明用のフローチャートである。 １．２．３・・・・・・アトム、４・・・・・・システ
ム管理装置、５・・・・・￥データバス（共通回線）。 々 １　　１＋１１　１　１　１ 　　　＋十暑　　　■　＋　１１ 止 Ｅｆミ 鋸 「」ζｈ

Claims (1)

【特許請求の範囲】
1. １、エンジンの運転状態を表わす各種の情報の内の少な
   くとも１の検出結果に基づいて上記エンジン制御用のデ
   ータを演算する方式のエンジン制御装置において、上記
   各種の情報を検出するための少なくとも１のセンサ手段
   と、上記制御用のデータによりエンジンの運転状態を制
   御する少なくとも１のアクチュエータ手段のそれぞれに
   搭載されたコンピュータ・ユニットと、これらコンピュ
   ータ・ユニットのそれぞれに搭載されたデータ・バック
   アップ手段と、上記コンピュータ・ユニット間を接続す
   るデータバスと、このデータバスに結合した外部接続手
   段とを設け、上記データバスを介してのデータの授受に
   よりエンジン制御が遂行されるように構成すると共に、
   上記コンピュータ・ユニットのそれぞれに対して、所定
   の管理装置から任意にアクセスし得るように構成したこ
   とを特徴とする自律分散型エンジン制御装置。