JP3803245B2 - 自動変速機制御ユニット - Google Patents
自動変速機制御ユニット Download PDFInfo
- Publication number
- JP3803245B2 JP3803245B2 JP2000369161A JP2000369161A JP3803245B2 JP 3803245 B2 JP3803245 B2 JP 3803245B2 JP 2000369161 A JP2000369161 A JP 2000369161A JP 2000369161 A JP2000369161 A JP 2000369161A JP 3803245 B2 JP3803245 B2 JP 3803245B2
- Authority
- JP
- Japan
- Prior art keywords
- control
- software
- application software
- automatic transmission
- control unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- Y02T10/47—
Landscapes
- Control Of Vehicle Engines Or Engines For Specific Uses (AREA)
- Combined Controls Of Internal Combustion Engines (AREA)
- Control By Computers (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、自動車用制御ユニットに係り、特に、エンジン、変速機、ブレーキ及びサスペンション等を制御する自動車用制御ユニットに関する。
【０００２】
【従来の技術】
最近、自動車制御にシングルチップマイコンを搭載した制御ユニットが用いられてきている。シングルチップマイコンは、中央演算処理装置（ＣＰＵ）の演算に必要なメモリ（ＲＯＭ、ＲＡＭ等）及びＡ／Ｄ変換器等を一括して内蔵している。そのため、全体として小型化が図れるとともに、使い易さ、処理時間の速さなどの点からも有利である。
【０００３】
【発明が解決しようとする課題】
しかしながら、前記従来技術においては、制御仕様の変更等によりソフトウェア、ハードウェアが変更になった場合に、拡充の面でかなり制限されるという問題点があった。また、自動車制御にシングルチップマイコンを用いた場合、ハードウェアに制限を受けてソフトウェアを作成する必要が生じ、特に、燃費向上、排気浄化等を行う場合は、入出力点数の増加や機能の追加が必須となり、その都度新たに全てのハードウェア、ソフトウェアを作り直す必要があるという問題点があった。
【０００４】
さらに、種々の制御を行うためにＲＯＭの中に書き込まれた制御ソフトがアセンブラ言語で表現されているため、そのプログラムの内容及び作成手法は専門家にしか解読できないような、いわば属人的なものであった。そのため、特に、実際のアプリケーションソフトの作成段階において、最初のプログラマー以外の者には、ソフトウェア内容の詳細が理解できないのみならず、別の機能のソフトを追加する場合には、始めから全部作成し直す必要があった。
【０００５】
本発明は、このような問題に鑑みてなされたもので、その目的は、シングルチップマイコンを用いた場合でも、入出力信号数の増加や機能の追加を容易にし、しかも、制御ユニットのプログラム変更を容易にする自動車用制御ユニットを提供することにある。
【０００６】
【課題を解決するための手段】
前記目的を達成するために、本発明に係わる自動変速機制御ユニットは、基本的には、スロットル開度を検出するセンサからの情報、空気流量を検出するセンサからの情報、水温を検出するセンサからの情報のうちの何れか１つ以上の情報が入力される入力部と、自動変速機の油圧を制御するアクチュエータ、変速位置を制御するソレノイドのうちの何れか１つ以上のアクチュエータを制御する信号を出力する出力部と、前記アクチュエータを制御して自動変速機を制御するためのプログラムが格納されたメモリと、前記プログラムを演算実行する中央演算処理部と、を備え、前記プログラムは、インターフェースソフト及びアプリケーションソフトを有し、前記アプリケーションソフトは、前記アクチュエータを制御する演算を行うための機能を有し、前記インターフェースソフトは、前記アプリケーションソフトと前記入力部との間の信号を授受する演算を行うための機能を有し、前記インターフェースソフトから前記アプリケーションソフトへの信号の授受は、関数を用いて行なわれ、前記メモリ及び中央演算処理部はシングルチップマイコンとして構成されることを特徴とし、入出力点数の増加や機能の追加に即対応可能な制御ユニットの構成とした。
【０００７】
【作用】
このように構成された本発明によれば、自動車制御にシングルチップマイコンを用いた場合でも、入出力点数の増加や機能の追加に対する対応が容易になり、インターフェースソフトの書換えのみでアプリケーションソフトが永続的に使え、更にコアユニットの作り換えが不必要となるため、プログラムを含めた制御ユニットの開発を容易にすることができる。
【０００８】
【実施例】
以下、本発明の実施例を図面に基づき詳細に説明する。なお、以下の実施例を説明するための図において、同一機能を有するものは同一符号を付し、その繰り返しの説明は省略する。
図１、２に本発明に係わる自動車用制御ユニットの一実施例を示す。
【０００９】
図１にコアユニット１の概略の一例を示す。コアユニット１は、アプリケーションソフトとＯＳ（Operating System）を接続するインターフェースソフトが、第１のメモリである内部ＲＯＭ２に内蔵されたインターフェースソフト記憶手段、前記アプリケーションソフトとインターフェースソフトを演算実行する中央演算処理装置（ＣＰＵ）３、演算結果等をメモリする第２のメモリであるＲＡＭ（書換え可能なメモリ）４及び制御ユニット拡張用のＩ／Ｏ（Input/Output）、メモリ等をバスあるいはＬＡＮ等を介して通信する拡張手段５から構成されている。
【００１０】
内部ＲＯＭ２内のインターフェースソフトは、割込み処理、タスクディスパッチャ、デバッグ機能、学習制御等の自動マッチング機能、ポート割付機能及び標準自動車Ｉ／Ｏ処理等（後述する）が含まれている。また、内部ＲＯＭ２には自動車メーカ等で作成するアプリケーションソフトも書き込むことができる。拡張手段５は入出力点数の増加や機能の追加に伴う外付けのＩ／Ｏ（後述する）、ＲＯＭ等のためのものである。
【００１１】
図２は拡張した場合のユニット構成図の一例である。図２において、図１で示したコアユニット１の拡張手段５に、バスあるいはＬＡＮ（Local Arear Network ）等の通信線を介して自動車用拡張Ｉ／Ｏ６及び外付けＲＯＭ７が付加的に連結されている。この拡張Ｉ／Ｏ６には、ソフトウェア的タイマあるいはハードウェア的タイマが存在する。そして、ハードウェア的タイマは、例えば点火時期制御や燃料制御のように、時間を精密に合わせる場合等の高精度制御に用いられ、ソフトウェアタイマはメータのようなラフな制御に用いることができる。また、前記拡張Ｉ／Ｏ６は、例えばプログラム可能な入出力装置であり、コアユニット１内のＣＰＵ３でデータをレジスタに書き込み、パルス幅変調（ＰＷＭ：Pulse Width Modulation）等の信号を出力することが可能なものである。なお、内部ＲＯＭ、外付けＲＯＭは電気的に書換え可能なメモリ（フラッシュメモリ、ＥＥＰＲＯＭ）を用いることもできる。
【００１２】
このようにして、図１に示したコアユニット１のバージョンが例えば４気筒エンジンに対応したものであって、次に、例えば６気筒エンジンに対応すべく制御を増加させる場合には、外付けＲＯＭ７に制御内容を入力し、かつ、増加した制御量を拡張Ｉ／Ｏ６を介してアクチュエータ（図示せず）に信号を出力するようになっている。
【００１３】
次に、図３、４に本発明の他の実施例を示す。
図３は拡張なしの場合の具体的ユニット構成図の一例である。図３において、拡張なしの場合は、コアユニット１がそのまま標準ユニット８となる。拡張手段５はＩ／Ｏポートの一部であり、したがって、拡張手段５も、センサＡ、Ｂ及びアクチュエータＡ、Ｂ等のＩ／Ｏポートとして使用できる。また、制御ユニット９はコアユニット１、センサ信号の処理を行うHard Filter１０及びアクチュエータ信号の増幅を行うパワー回路１１から成る。
【００１４】
図４は拡張あり場合の具体的ユニット構成図の一例である。図４において、拡張した場合は、コアユニット１の拡張手段５がコントロールバス、アドレスバス及びデータバスとして用いられる。上記３つのバスによって自動車用拡張Ｉ／Ｏ６及び外付けＲＯＭ７がコアユニット１と接続され、標準ユニット１２が構成されている。この場合、Ｉ／Ｏポートとして用いていた拡張手段５が拡張用に使用されるため、センサＡ、Ｂ及びアクチュエータＡ、ＢのＩ／Ｏポートがなくなってしまう。そこで、拡張Ｉ／Ｏ６は上記コアユニット１で減った分のＩ／Ｏポートの数を含めたポート数とする必要がある。ここで、一例として、センサＣ、Ｄ及びアクチュエータＣが増えたとすると、上記３つのポートとセンサＡ、Ｂ及びアクチュエータＡ、Ｂを加えたＩ／Ｏポート数が用意されることになる。制御ユニット１３は、標準ユニット１２、センサＣ、Ｄ及びアクチュエータＣ用のHardFilter１４及びパワー回路１５、センサＡ、Ｂ及びアクチュエータＡ、Ｂ用のHard Filter１０及びパワー回路１１から構成される。
【００１５】
図５はコアユニット１自体の拡張構成図の一例である。コアユニット１内には、ＣＰＵ３、内部ＲＯＭ２、ＲＡＭ４、拡張手段５を含んだＩ／Ｏ１６、Ａ／Ｄ１７、タイマ１８、自動車用拡張Ｉ／Ｏ６及び外付けＲＯＭ７等の外部メモリからアクセスを高速に実行するためのキャッシュメモリ１９が設けられている。すなわち、このキャッシュメモリ１９は、次に読み込まれる外付けＲＯＭ７からのデータを予めメモリさせるもので、ＣＰＵ３はわざわざ外付けＲＯＭ７までアクセスしなくても、キャッシュメモリ１９から次に読み込まれるデータにアクセスすることができるため、外付けＲＯＭ７の内容を読み込むのに要する時間を節約することができ、応答性を向上させることができる。また、これらは全てバス２０で接続される。
【００１６】
図６〜８は各仕様に応じた拡張構成図の一例を示す。
図６は、例えば４又は６気筒エンジンに用いる場合の標準ユニット構成の例である。図６において、適用対象車における制御対象が４又は６気筒エンジン制御のみである場合には、制御項目やＩ／Ｏ数等がさほど多くないため、コアユニット１のみで対応することができ、コアユニット１がそのまま標準ユニットとなる。この場合、内部ＲＯＭ２にアプリケーションソフトとインターフェースソフトを書き込んで制御を行う。
【００１７】
図７は、図６の構成に故障診断を加えた６気筒エンジン、あるいは自動変速機制御を加えた６気筒エンジンの場合の標準ユニット構成の一例を示す。図７において、適用対象車が故障診断を加えた６気筒エンジン、あるいは自動変速機制御を加えた６気筒エンジンの場合は、コアユニット１に自動車用拡張Ｉ／Ｏ２１及び外付けＲＯＭ７（ａ）を拡張して設け（拡張部１）、当該６気筒エンジンの仕様で必要なポート数の確保、並びに、制御項目増加に伴うメモリの確保を行う。この場合、ソフトは、追加分を外付けＲＯＭ７（ａ）に記憶させるか、あるいは内部ＲＯＭ２にインターフェースソフトを、外付けＲＯＭ７（ａ）にアプリケーションソフトを記憶させることもできる。
【００１８】
図８に６気筒統合制御を行う場合の標準ユニット構成の一例を示す。適用対象車が、例えば、故障診断、自動変速機、定速走行制御、計器類等のインパネ制御などの多数の制御を付加した６気筒エンジンを搭載した車両、すなわち６気筒統合制御の追加機能を増大させた車両の場合には、図８に示すように、図７の構成に加え、更に拡張Ｉ／Ｏ２２及び外付けＲＯＭ７を拡張して対処する（拡張部２）。なお、図８の場合も図７と同様に、外付けＲＯＭ７及び７（ａ）が拡張された場合は、追加分を外付けＲＯＭ７，７（ａ）に記憶させるか、あるいは内部ＲＯＭ２にインターフェースソフトを、外付けＲＯＭ７（ａ）及び外付けＲＯＭ７にアプリケーションソフトを記憶させることができる。後者の場合は、インターフェースソフトとアプリケーションソフトが分離されているため、アプリケーションソフトのデバッグが容易になる。
【００１９】
このように、入出力点数の増加やソフトを含めた機能の追加に対してすぐに対処できることもコアユニット１と拡張手段５の特徴である。
図９はコアユニットを用いた場合のエンジンＡＴ（Automatic Transmission）制御ユニット構成図の一例である。図９において、コアユニット１内の内部ＲＯＭ２には、エンジン及びＡＴ制御で高速演算が必要なアプリケーションソフト（例えば、点火燃料制御等のハード的割り込み処理）とインターフェースソフトが書き込まれている。また、コアユニット１には、Ａ／Ｄ１７の有効利用のため、複数のアナログ信号を状況に応じて選択するマルチプレクサ（ＭＰＸ）２３が備えられており、スロットル開度ＴＶＯ、空気流量信号Ｑａ、水温Ｔｗ等の信号処理を行う。さらには、スイッチ信号（アイドルＳＷ）及び車速Ｖｓｐ等のパルス信号が入力される。コアユニット１でのＡＴ制御の出力信号として、変速機の油圧を制御するライン圧ＰＬ、変速位置を制御するソレノイド信号ｓｏｌＡ、ｓｏｌＢが出力される。また、エンジン制御はタイマを数多く用いるのでエンジン制御用拡張Ｉ／Ｏ２４が必要となる。エンジン制御用拡張Ｉ／Ｏ２４は、多くのタイマを内蔵したものである。そこで、エンジンの回転信号ＰＯＳ及び気筒判別信号ＲＥＦを拡張Ｉ／Ｏ２４に入力し、燃料噴射量ＩＮＪ、点火時期ＩＧＮ、アイドル制御ＩＳＣを出力する。また、外部ＲＯＭ７にはエンジンＡＴ制御の低速演算で十分なアプリケーションソフト（例えば、変速点制御、ロックアップ制御）を書き込むようにする。
【００２０】
図１０はコアユニットを用いた場合のＡＢＳ（Antiskid Brake System ）トラクション制御ユニット構成図の一例である。コアユニット１内の内部ＲＯＭ２にはＡＢＳ制御用のアプリケーションソフトと、ＡＢＳ制御とトラクション制御で必要なインターフェースソフトが書き込まれている。また、Ａ／Ｄ１７の有効利用のため、複数のアナログ信号を状況に応じて選択するＭＰＸ（マルチプレクサ）２３が備えられており、自動車の絶対車速を求めるためのＧ（加速度）センサ等の信号処理を行う。さらに、駆動輪側の速度である車速Ｖｓｐ、非駆動輪側の速度である車輪速（右前）及び車輪速（左前）等のパルス信号が入力される。また、コアユニット１でのＡＢＳ制御の出力信号として、ブレーキ圧を制御するＰＷＭ信号Ｄｏｕｔが出力される。また、トラクション制御の機能を付加する場合は、トラクション制御用拡張Ｉ／Ｏ２５を用いて、エンジントルクを低減するためのスロットル開度、点火時期リタード量を出力する。また、外部ＲＯＭ７にはトラクション制御のアプリケーションソフトを書き込むようにする。このように、本図示例では、ＡＢＳ制御のユニットを作成して標準化を行い、それに拡張してトラクション制御を行うようにしたものである。
【００２１】
次に、制御ユニット間をＬＡＮ（Local Area Network）で連結させた場合の実施例について説明する。
図１１は、エンジンＡＴ制御ユニット及びＡＢＳトラクション制御ユニットの両方のユニットを使用する車両において、両ユニットをＬＡＮで連結させた場合のシステム構成図の一例である。図７、図８で示したエンジンＡＴ制御ユニット２７、ＡＢＳトラクション制御ユニット２８等がＬＡＮ（データ通信線）２６で連結されている。ＬＡＮ２６と制御ユニット２７のバス１２９は通信コネクタ１３０、通信回路１３１でデータ通信を行う。また、ＬＡＮ２６と制御ユニット２８のバス１３２は通信コネクタ１３３、通信回路１３４でデータ通信を行う。例えば、エンジンＡＴ制御ユニット２７で演算したエンジントルク等のデータをＡＢＳトラクション制御ユニット２８に送信し、車輪空転時のエンジントルク低減制御（スロットル開度減少，点火時期リタード及び燃料量減少等）をエンジントルクフィードバックで実行し制御精度を向上させる。
【００２２】
図１２は演算ユニット３３とＩ／Ｏユニット３２とを分割し、これら相互間をＬＡＮ１２６で通信した場合の構成図の一例である。Ｉ／Ｏユニット３２はＣＰＵ３、内部ＲＯＭ２、ＲＡＭ４、拡張手段５を含んだＩ／Ｏ１６、Ａ／Ｄ１７、タイマ１８、ＭＰＸ２３及びエンジンＡＴ制御用拡張Ｉ／Ｏ１２４から成る。Ｉ／Ｏユニット３２ではセンサから入力された信号をフィルタ処理，Ａ／Ｄ変換処理等を実行し、その処理データをＬＡＮ１２６を介して演算ユニット３３に送信する。そして、エンジンＡＴ演算ユニット３３では送信されたデータを用いて燃料噴射幅ＩＮＪ、点火時期ＩＧＮ、アイドル制御量ＩＳＣ、変速機のライン圧ＰＬ等が演算され、その演算結果をＬＡＮ１２６を介してＩ／Ｏユニット３２に送信する。そして、インターフェースソフトを含むコアユニット１内のＩ／Ｏ１６及びエンジンＡＴ制御用拡張Ｉ／Ｏ１２４より上記出力信号が出力される。この場合、演算ユニット３３はＩ／Ｏユニット３２と同じコアユニット１を用いているため、同様の機能を持っている。しかし、演算ユニット３３の内部ＲＯＭ２には演算で用いるアプリケーションソフトのみが書き込まれている。ＬＡＮ１２６とユニット３２、３３との通信はそれぞれ通信コネクタ１３６，１３９、通信回路１３７，１４０で実行する。また、上記通信コネクタ１３６，１３９、通信回路１３７，１４０は各制御ユニットのＣＰＵの命令で動作する。
【００２３】
このように、本図示例では、インターフェースソフトというＩ／Ｏ処理ソフトを内部ＲＯＭ２に書き込み、一つのユニットでＩ／Ｏユニット３２を構成したものであり、したがって、例えばＡＢＳトラクション制御ユニットやエンジンＡＴ制御ユニット等に入力される、同じ信号（オーバーラップ信号）をＩ／Ｏユニット３２に一本化して入力することができ、Ｉ／Ｏの共用化を図り、部品点数の削減を可能とする。
【００２４】
以下、前述のインターフェースソフトの概略を実施例により説明する。
前述したように、インターフェースソフトとは、ＯＳとアプリケーションソフトとの仲介をなすソフトである。そのため、アプリケーションソフト提供メーカはＯＳを考慮することなくアプリケーションソフトを作成することができ、ソフト開発が容易になる。
【００２５】
図１３から図１７に制御ユニットによる入力信号処理の比較を示す。
図１３及び図１４は従来の空気流量センサ信号の処理構成である。図１３は空気流量Ｑａを検出及び演算する際にホットワイヤ（ＨＷ）式空気流量計を用いた場合である。上記空気流量計の信号は、まず 制御ユニット３８に設けられたハードフィルタ１３８で信号のノイズ除去を行い、シングルチップマイコン１４０のＡ／Ｄ変換器２４０に入力される。そして、Ａ／Ｄ変換器２４０で変換された信号は関数Ａ４０で空気流量Ｑａに変換される。また、図１４のように吸気管内圧力計を用いた場合は、制御ユニット３９に設けられたホットワイヤ（ＨＷ）式空気流量計とは異なるハードフィルタ１３９で信号のノイズ除去を行い、シングルチップマイコン１４１のＡ／Ｄ変換器２４１に入力される。そして、Ａ／Ｄ変換器２４１で変換された信号は関数Ｂ４１で空気流量Ｑａに変換される。
【００２６】
図１５はインターフェースソフト内蔵の内部ＲＯＭ１４３を搭載した標準ユニット４２の入力信号処理構成の一例である。標準ユニット４２を用いた場合は、図１３及び１４で示した吸気管内圧力計あるいはＨＷ式空気流量計のいずれのセンサにも対応可能となる。つまり、内部ＲＯＭ１４３のインターフェースソフトが上記２つのセンサのフィルタリング及び関数処理を実行するからである。まず、入力される信号は標準ユニット４２のＡ／Ｄ変換器１４２でディジタル化され、内部ＲＯＭ１４３のインターフェースソフトによる処理が行われる。次に、上記ハードフィルタ１３８，１３９の代わりにディジタルフィルタ２４３を用い、ソフト的にそれぞれのセンサ信号に対応したカットオフ周波数を設定するようにしておく。更に、各センサ信号によって異なる特性を持つ関数の代わりに高次関数４３（Ｑａ＝ΣＫｉ＊Ｖ Ｋｉ：次数，Ｖ：ディジタル化した電圧信号）を用いて各信号に対応した次数Ｋｉを設定し、それぞれに対応した関数を作り、演算して空気量Ｑａの算出を行う。これにより各種のセンサ信号入力をソフト的に切り替えることが可能となる。すなわち、インターフェースソフトにより、前記関数Ａ及びＢの特性を高次関数４３で作出することができ、Ｑａは同一のポートでどのような方式でも算出することができる。
【００２７】
図１６は可変式ハードフィルタを用いた入力信号処理構成の一例である。制御ユニット１４４には、センサ信号の種類によって可変抵抗等を変化させるとともに、カットオフ周波数を変えて信号に対応したフィルタリングを実行する可変式ハードフィルタ４４、Ａ／Ｄ変換器１４７、インターフェースソフト（関数Ａ，Ｂ等）から成る標準ユニット２４４が設けられている。まず、入力される信号を上記可変式ハードフィルタ４４でノイズ除去を実行し、標準ユニット２４４に入力する。そして、標準ユニット２４４内にそれぞれのセンサ信号に対応した関数、例えばＨＷ式空気流量計式なら関数Ａ４５、吸気管内圧力計式ならば関数Ｂ４６というような演算関数が備えられており、セレクタ４７により入力センサ信号に対応した関数を選択して空気量Ｑａが算出される。
【００２８】
図１７は使用センサ分にハードフィルタを備えた入力信号処理構成の一例である。制御ユニット１４８において、各種のセンサ（ＨＷ式空気流量計，吸気管内圧力計）に対する入力端子及びそれぞれに固有のハードフィルタ４８，４９を備えておき、標準ユニット１４９内に備えた関数Ａ４５，関数Ｂ４６，セレクタ４７により空気量Ｑａを算出する。
【００２９】
図１８はインターフェースソフトによるポート割当機能の一例を示す概略図である。図１８（ａ）は標準ユニット５０を用いたＨＷ式空気流量計式の６気筒エンジン制御、図１８（ｂ）は吸気管内圧力計式の４気筒エンジン制御の入出力ポート割当構成の一例を示す。
図１８（ａ）の場合、ＨＷ式空気流量信号Ｑａ，エンジン回転数信号Ｎｅ，水温信号Ｔｗ，酸素センサ信号Ｏ２等の信号が入力ポート、また、６気筒分の燃料噴射信号ＩＮＪ，ＤＩＳＴ（Distributor ）方式の点火信号ＩＧＮ及びＩＳＣ（Idle Speed Control）等の信号が出力ポートとして割り当てられる。この標準ユニット５０を図１８（ｂ）仕様の４気筒エンジンに用いる場合は、ＩＮＪパルス信号が６気筒の６本から４気筒の４本に減少するため、２本のポートが余る。しかし、吸気管内圧力計を使用するエンジン制御では、空気流量を演算する際、吸気温補正、排圧補正が必要となる。そこで、出力ポートで余った２本を上記吸気温及び排圧の入力ポートとして用いれば有効な標準ユニット５０使用が実現できる。なお、図１８（ｂ）では、空気流量信号Ｑａに代えて、吸気管内圧力信号Ｐｍが入力ポートに割り当てられている。このような、ポート割当機能を標準ユニット５０のインターフェースソフトに持たせることによりユニットの有効利用が実現できる。また上記吸気温及び排圧の信号取り込みに関しては、マルチプレクサ等を標準ユニット５０との間にハード的に組み込み、切り替えることで柔軟性を持たせる。このようにエンジン仕様及びセンサ仕様が違った場合でもインターフェースソフトのポート割当機能により効率の良い入出力信号変更が可能になる。
【００３０】
図１９はインターフェースソフトによる入力信号の組み合わせ処理の構成図の一例である。組み合わせ処理とは、センサ等からの入力信号の組み合わせにより別の信号を生成する処理であり、この処理をインターフェースソフト５７で実行する。例えば、エンジン回転５１と車速５２から処理Ａを介してギヤ比信号５３を、また、エンジン回転５１とタービン回転５４から処理Ｂを介してタービントルク５５及び出力軸トルク５６を演算する。このような処理機能をインターフェースソフト５７に持たせることにより、ユーザーつまりアプリケーションソフト開発側がＲＡＭの各アドレスに格納された、前記ギヤ比信号等のデータにアクセスすれば、何時でも自由にその内容をみることが可能となる。このような組み合わせ処理の実行により、今後の制御項目増大による必要パラメータの増加が生じた場合でも新たなセンサの追加なしで対応が可能となる。
【００３１】
図２０はインターフェースソフトによるセンサ入力時の演算処理機能の一例を示す。現状のエンジン制御では、空気量センサ，水温センサ，スロットル開度センサ及びクランク角センサの信号Ａ／Ｄ変換あるいはパルス数計測等の信号処理を施した値が直接アプリケーションソフトで用いられるわけではない。例えば、空気量センサからの信号は、一度テーブルを参照し補間計算を施して、初めてアプリケーションソフトで使用可能な吸入空気量指数ＱＡを求めることができる。このように、アプリケーションソフトで必要な信号、すなわち吸入空気量指数ＱＡ，吸入空気量定数ＱＳ，水温ＴＷＮ，水温格子検索用ＴＷＫ，スロットル開度ＡＤＴＶＯ，ＴＶＯ１Ｓ及びエンジン回転数ＬＮＲＰＭ，ＨＮＲＰＭ，ＭＮＲＰＭの演算をインターフェースソフト５８に設けておくことによりソフト開発が容易になる。また、前記吸入空気量指数ＱＡ，吸入空気量定数ＱＳ，水温ＴＷＮ，水温格子検索用ＴＷＫ，スロットル開度ＡＤＴＶＯ，ＴＶＯ１Ｓ及びエンジン回転数ＬＮＲＰＭ，ＨＮＲＰＭ，ＭＮＲＰＭの各データをＲＡＭに格納しておくことにより、これらアプリケーションのデータは、ＲＡＭにアクセスすれば何時でもみることができる。
【００３２】
次に、インターフェースソフトの記述方法、つまりソースリストのフローの実施例を示す。
図２１はインターフェースソフトによる時間割付の一例を示す概略図である。自動車制御にはさまざまなタイミングで起動する各制御のタスク及びサブルーチンがあり、それぞれがある一定周期で動作している。Ｃ言語記述では時間管理及びタイミング割付が困難であるため、自動的割当て機能をインターフェースソフトにもたせた。エンジン制御アプリケーションソフトにはクランク角度割り込み、点火パルス発生、インターバル割り込み、エンジン回転数取り込み処理といった各種の起動タスクが存在しており、それぞれが固有の要求タイミングを持ち、それに見合った回転または時間周期で起動している。また他のＡＴ制御やＡＢＳ制御アプリケーションソフトに対しても同様である。このようにさまざまな要求タイミングがある各アプリケーションソフト及び内部の各タスクをインターフェースソフトの自動的割当て処理機能においてそれぞれの要求タイミングを判断してマイコンの起動周期設定に必要なタイマ等の初期設定さらに要求タイミングでの処理内容としてベクタアドレスの割付を自動的に行うようにしている。
【００３３】
図２２は図２１の詳細な制御フローチャートの一例である。たとえばＣ言語記述アプリケーションソフトにおいて、タスク起動タイミングの記述形式を例としてＪＯＢ＝要求タイミングとした場合に、ＪＯＢの内容が何であるかを各起動タスクごとに判別プログラムを動作させ、ＪＯＢ＝Ａ（５９）ならマイコンへ２ｍｓ周期処理タイミングの初期設定を行い、さらに２ｍｓ周期処理としてベクタアドレスの割付６０をする。ＪＯＢ＝Ｂ（６１）なら上記と同様にマイコンへ４ｍｓ周期処理タイミングの初期設定を行い、また４ｍｓ周期処理としてベクタアドレスの割付６２を行い、ＪＯＢ＝ＲＥＦ（６５）ならば回転周期処理の初期設定をマイコンに行い、起動タスクのベクタアドレスを割り付ける（６６）。また、ＪＯＢ＝Ｘ（６３）ならばユーザが要求した独自のタイミングたとえば２０ｍｓ周期とするとそれに応じたマイコンへの初期設定及びベクタアドレスの割付６４を行うようにしている。このような機能をインターフェースソフトに持たせておくことで自動車制御ソフトがＣ言語記述に移行した際の時間管理及びタイミング割付の問題を回避することができる。
【００３４】
図２３はインターフェースソフトによる割り込みレベル割付のフローチャートの一例である。基本的には時間割付のフローと同様に、各制御内の起動タスクからの要求割り込みレベルのラベルが何であるか判別して、そのラベルに応じて優先順位を各タスクへ割当て、マイコンへの優先順位の初期設定を自動的に行うようにしている。要求レベルがＬ７かを判断６７し、ｙｅｓならば各対象ＪＯＢを割り込みレベル７として優先順位設定６８を行う。以下同様に、要求レベルを判別（６９，７１，７３）し、各レベル設定（７０，７２，７４）を行う。各制御アプリケーションソフトにおいて、数多くのタスクが個々のタイミングで起動する中で、各タスクの割り込みレベルの設定は、リアルタイム性が重視される自動車制御では重要な役割をもち、Ｃ言語記述化を図った場合には不可能な割り込みレベルの記述が可能となる。
【００３５】
表１はタイミング及び優先順位割付のためのＣ言語記述仕様である。自動車制御に必要な大体のタスク起動タイミングをピックアップして予め仕様化しておき、それを各制御のソフトを開発するときにタスクに要求するタイミング及び優先順位を仕様の中から選択し、タスクの先頭に例えば２ｍｓ周期のタスクで優先順位７ならばラベルＡ，Ｌ７を、４ｍｓ周期のタスクで優先順位５ならばラベルＢ，Ｌ５を記述すればよい。また回転周期のラベルも数個設けておく。さらに、ユーザ（アプリケーションソフト開発側）設定用のラベルも備えることで要求タイミングを自由に設定できる。このように、アプリケーションソフトはそのままで、インターフェースソフトにおいてマイコンへの初期設定値の決定及び割付を行うこと、つまりインターフェースソフトの改良を行うだけで各種マイコン（ＣＰＵ）への対応が容易に行うことができる。
【００３６】
【表１】
【００３７】
さらに、インターフェースソフトの処理機能として対応マイコンで最適と考えられる入出力ポートの割付けを行う。標準ユニットを用いて制御対象の異なった自動車制御を行う場合には、入出力ポートは標準ユニットにより数が限られており、４気筒と６気筒の制御には別々の入出力ポートの割当てが要求される。そのため、最適入出力ポートの割当てのパターンを設定しておき、自動車制御ソフトが、どのタイプを制御しようとしているかを判断してポート割当てのパターンを自動的に選択し、マイコンへの入出力信号を決定するようにする。制御対象に対応した最適な入出力ポートの割当てをそれぞれパターン化して備えておく。
【００３８】
図２４は最適入出力ポート割当のパターン決定のフローチャートの一例である。まず、制御対象が４気筒エンジン制御ならば、次に空気量測定の方式を判別して空気流量計式ならばパターンＡを、吸気管内圧力計式ならばパターンＢを割当て、６気筒エンジンの制御においてもパターンＣ，パターンＤ等をそれぞれの測定方式のタイプを判別し、それに応じて割当てを行う。これにより共通ユニットを用いての有限である入出力ポートの割当てをパターン化することで、自動的に制御対象に対応した割当てが可能となる。
【００３９】
図２５はＲＡＭ領域内における多用データ一括集団配置の一例である。ＲＡＭ領域には独自開発されたエンジン，ＡＴ，ＡＢＳ制御用のデータがそれぞれ確保されるが、その中で２つ以上の制御内で使われる使用頻度の高いデータを多用データとして集団配置する。これによりベースレジスタを活用することでプログラムのＲＯＭ容量を減らすことができる。また、各制御アプリケーションソフト間同志での通信いわゆるデータ提供を行うにしても多用データとして一括配置しておいた方が１ブロックでデータ参照が可能となる。
【００４０】
図２６は多用データ一括配置のフローチャートの一例である。独自に開発されたエンジン制御、ＡＴ制御、ＡＢＳ制御のＣ言語記述アプリケーションソフトを用いて、その流れを説明する。図２６において、まず、エンジン制御に使用するために宣言された変数が宣言の順番にＲＡＭ領域に割り付けられる７５。ここでＲＡＭ領域内の多用データ割当て領域の先頭アドレスを＃ＡＤＤとしておき、ＡＴ制御で宣言されている変数にエンジン制御変数と同一変数がないか検索７６する。同一変数が見つかればそのデータをＡＤＤ番地に格納し、アドレスＡＤＤをインクリメントする。すべてのＡＴ制御の宣言変数をエンジン制御変数と照らし合わせ終わるまで繰り返す。
【００４１】
ＡＴ制御変数中を検索終了後７７、次に、ＡＢＳ制御において宣言した変数についてエンジン制御及びＡＴ制御変数に同一変数がないか検索７８を行い、見つかれば、まず多用データ割当て領域にすでに多用データとして配置されていないかを判別し、なければＡＤＤ番地にそのデータを格納して、上記と同様にＡＤＤをインクリメントしながら全ての変数の照合が終了するまで繰り返す。
【００４２】
このような手順を経ることにより、ＲＡＭ領域内に多用データとして一括して配置することが可能となる。また、エンジン制御だけをみても数多くの起動タスクから構成されており、各タスクにおいて数個の使用変数が宣言されている。このように、１つの制御中にも使用頻度の高いデータが多く含まれている可能性があり、同様の簡単なフロー構成を用いることにより、制御間のみならず各制御内のタスク間における多用データの探索及び一括配置をも行うことができる。
【００４３】
次に、監視プログラムにより異常な制御箇所を発見するための一実施例について説明する。
図２７は監視プログラムを利用した異常箇所発見のフローチャートの概略図の一例である。図２７において、自動車制御の各制御部並びに各タスクには、特有のエラーコードが設定してある。監視プログラムは、エラーコードが発生した時にコード識別により、エンジン制御部か、ＡＴ制御部か、あるいはＡＢＳ制御部かを判別して、それぞれの制御部に設定されたフェール対策を起動するようにしてフェールセーフを行う。また、このようなエラーコードを各制御部とその中の各タスクに設定しておくことにより、１つにした自動車制御の膨大なアプリケーションソフトのデバッグを行う際に、エラーコードを識別すれば、どの制御アプリケーションソフトにおける、どのタスクにおいて異常が発生したか等のバグ要因の発見を容易に行うことが可能となる。
【００４４】
さらに、インターフェースソフトにおいて独自開発した各制御アプリケーションソフトの各々のタスクには、タスク起動時に起動フラグをたてるフラグ操作プログラムが付設されている。また、インターフェースソフトには、フラグ操作プログラムによる起動フラグをある一定周期で監視する監視プログラムが設けられている。この監視プログラムは、各タスクの処理時間を演算及び管理を行うとともに、ＣＰＵ負荷率の診断をも行う。そうして監視プログラム内に設定された各タスクの規定処理時間内にタスク処理が終了しなかったり、あるいは各制御に割り当てられたＣＰＵ負荷率を越えた場合に、予め設定された識別可能なエラーコードを出力させてフェールセーフ対策やデバッグ処理に活用する。 監視プログラムを利用して異常箇所を発見するための手法としては、例えば、ソフトウェアタイマを引用したフェールセーフソフト、監視内容を拡張した起動タスク監視プログラム、ウォッチドッグタイマを用いたマクロ処理時間監視の方式などが考えられる。
【００４５】
前記ソフトウェアタイマを引用したフェールセーフソフトは、たとえば、その処理時間監視タスクにおいて、複数のタスクを優先順位が高い順に並べておき、実行中のタスクの処理時間監視用のタイマをインクリメントする動作を行い、次に実行中のタスクが規定の処理時間内に終了しているかを調べるもので、予め設定しておいた規定処理時間とタイマのデータを比較して、規定時間を超過していれば各タスク特有のエラーコードを出力するようにしたものである。なお、前記規定処理時間は監視プログラムの起動周期をもとにしてその整数倍で決まるため、起動周期を可変させることにより何ｍｓにでも設定することができる。
【００４６】
監視内容を拡張した起動タスク監視プログラムは、たとえば、１つのソフト上に各制御のプログラムがあり、それらのタスクを実行した際に監視プログラムが実行タスクの処理時間の演算及び管理、並びに各制御によるＣＰＵ負荷率の監視を行えるようにしたものである。この起動タスク監視プログラムには、例えばエンジン制御、ＡＴ制御、共通制御等の各制御によるＣＰＵ負荷率を監視するためのプログラムが備えられている。このプログラムは、ＣＰＵに対する各制御の負荷をカウントし、ＣＰＵ負荷率の過占有として各制御関係のタスク（仕事）が全体の７０％を越えるとエラーとするような負荷率エラーの取り決めを行っておき、各制御部に用意されたカウンタが７０以上かを診断して、異常があればその制御部中の各タスクの優先順位の高いほうから処理時間を診断し、異常タスクを指すエラーコードを出力する。負荷率エラーが発生しなくてもＣＰＵ負荷率は、ＥＮＧＩＮＥ，ＡＴ，ＣＯＭＭＯＮ等の各制御部のカウンタから知ることができる。
【００４７】
ウォッチドッグタイマを用いたマクロ処理時間監視の方式は、たとえば、処理に異常が生じてウォッチドッグタイマのオーバーフロー設定時間内にタイマがクリアされないと、オーバーフローにより強制割り込み（ＮＭＩ）が発生して監視プログラムが動きだし、異常発生の直前のスタックポインタ（ＳＰ）をもとに各プログラムの格納されているアドレスとで比較し、異常発生のタスクを指すエラーコードを出力するものである。このように、ウォッチドッグタイマ方式は、プログラム規模は小さくて済むが、各タスクの状態を大雑把にしか監視できない。しかし、バグの発生しにくさではウォッチドッグタイマ方式の方が望ましい。
【００４８】
次に、インターフェースソフトに記述されるリストに係わる実施例について説明する。
図２８はインターフェースソフトに基本処理プログラムの組み込み関数化の一構成例である。エンジン回転取り込み９０，車速演算９１，タービン回転数９２，スロットル開度取り込みプログラム９３及びさまざまな周波数で使用される各フィルタの演算プログラム９４を関数化し、さらにＬＡＮ等の通信用の組み込みソフト９５も関数化してインターフェースソフトに持たせた。
【００４９】
図２９は一般的自動車制御用変数の定義及び宣言の関数化の一例である。膨大なフラグ変数や入出力信号等のＩ／Ｏ変数をインターフェースソフトに定義及び宣言してヘッダファイルとして関数化させる。フラグ変数等は最適Ｃ言語となるように、型宣言さらにビットフィールドを考慮して定義しておく。
図３０は組み込み関数の仕様の一例である。仕様化しておくことで制御ソフト開発側がヘッダファイルをインクルードし、定義済みの変数を利用して制御を構成することができ、また制御工程で信号取り込みや演算が生じた場合には、先に述べた基本処理関数の中から必要な処理関数を呼び出すようにすれば良い。これらの基本処理プログラムの関数化，一般的自動車制御用のＩ／Ｏ，変数を定義したヘッダファイルの関数化により、自動車制御ソフトの開発を簡略化することができる。すなわち、Ｉ／Ｏ処理等によりソフトウェアを標準化し、それを仕様書としてアプリケーションソフト開発側（ユーザー）に提示すれば、ユーザー側は、その仕様書を基に必要な機能ソフトをサブルーチン等により追加または変更することができ、機能アップを図ることができる。
【００５０】
図３１は基本処理関数の処理選択機能の手段の一例である。各制御のアプリケーションソフトからの基本処理関数の呼出しをする時に、引数により処理条件を選択する例を示す。例えば、エンジン回転取り込み関数には、回転数演算方式や取り込みサンプリング時間さらにパルス測定センサに関しても各種の手段が存在する。これらの手段に対応したプログラムをインターフェースソフトに持たせておき、開発側が引数により手段を選択し、これを記述することで開発側の要求を達成することができ、基本処理関数の汎用性が向上する。同様に、フィルタの演算においても引数にフィルタタイプ，カットオフ周波数，次数等をわたせばそれに対応したフィルタを設定できる。
【００５１】
以上、本発明の実施例を詳述したが、本発明は、前記実施例に限定されるものではなく、特許請求の範囲に記載された本発明を逸脱することなく種々の設計変更を行うことが可能である。
【００５２】
【発明の効果】
以上の説明から理解されるように、本発明によれば、自動車制御にシングルチップマイコンを用いた場合でも、入出力点数の増加や機能の追加に対する対応が容易になり、インターフェースソフトの書換えのみでアプリケーションソフトが永続的に使用可能となり、しかも、コアユニットの作り換えが不必要となるため、プログラムを含めた制御ユニットの開発が容易になる。
【図面の簡単な説明】
【図１】コアユニットの概略図。
【図２】拡張した場合のユニット構成図。
【図３】拡張なしの場合の具体的ユニット構成図。
【図４】拡張あり場合の具体的ユニット構成図。
【図５】コアユニット自体の拡張構成図。
【図６】４，６気筒エンジンに用いる場合の標準ユニット構成図。
【図７】故障診断を加えた６気筒エンジンあるいは自動変速機制御を加えた６気筒エンジンの場合の標準ユニット構成図。
【図８】６気筒統合制御の場合の標準ユニット構成図。
【図９】コアユニットを用いた場合のエンジン・ＡＴ制御ユニット構成図。
【図１０】コアユニットを用いた場合のＡＢＳ・トラクション制御ユニット構成図。
【図１１】ＬＡＮ（Local Area Network）を用いた場合のシステム構成図。
【図１２】演算ユニットとＩ／ＯユニットをＬＡＮで通信した場合の構成図。
【図１３】従来の空気流量（ＨＷ式）センサ信号の処理構成図。
【図１４】従来の空気流量（吸気管内圧力式）センサ信号の処理構成図。
【図１５】インターフェースソフト内蔵内部ＲＯＭ搭載した標準ユニットの入力信号処理構成図。
【図１６】可変式ハードフィルタを用いた入力信号処理構成図。
【図１７】使用センサ分にハードフィルタを備えた入力信号処理構成図。
【図１８】インターフェースソフトによるポート割当機能の概略図。
【図１９】インターフェースソフトによる入力信号の組み合わせ処理の構成図。
【図２０】インターフェースソフトによるセンサ入力時の演算処理機能を示す図。
【図２１】インターフェースソフトによる時間割付の概略図。
【図２２】時間割付の詳細制御フローチャート。
【図２３】インターフェースソフトによる割り込みレベル割付プログラムのフローチャート。
【図２４】最適入出力ポート割当のパターン決定のフローチャート。
【図２５】ＲＡＭ領域内における多用データ一括集団配置図。
【図２６】多用データ一括配置のフローチャート。
【図２７】監視プログラムを利用した異常箇所発見の簡単なフローチャート。
【図２８】基本処理プログラムの組み込み関数化の構成図。
【図２９】一般的自動車制御用変数の定義及び宣言の関数化の図。
【図３０】組み込み関数の仕様を示す図。
【図３１】基本処理関数の処理選択機能の手段を示す図。
【符号の説明】
１…コアユニット、２…内部ＲＯＭ、３…ＣＰＵ（中央演算処理装置）、４…ＲＡＭ（書き換え可能なメモリ）、５…拡張手段、６…拡張Ｉ／Ｏ、７…外付けＲＯＭ
【産業上の利用分野】
本発明は、自動車用制御ユニットに係り、特に、エンジン、変速機、ブレーキ及びサスペンション等を制御する自動車用制御ユニットに関する。
【０００２】
【従来の技術】
最近、自動車制御にシングルチップマイコンを搭載した制御ユニットが用いられてきている。シングルチップマイコンは、中央演算処理装置（ＣＰＵ）の演算に必要なメモリ（ＲＯＭ、ＲＡＭ等）及びＡ／Ｄ変換器等を一括して内蔵している。そのため、全体として小型化が図れるとともに、使い易さ、処理時間の速さなどの点からも有利である。
【０００３】
【発明が解決しようとする課題】
しかしながら、前記従来技術においては、制御仕様の変更等によりソフトウェア、ハードウェアが変更になった場合に、拡充の面でかなり制限されるという問題点があった。また、自動車制御にシングルチップマイコンを用いた場合、ハードウェアに制限を受けてソフトウェアを作成する必要が生じ、特に、燃費向上、排気浄化等を行う場合は、入出力点数の増加や機能の追加が必須となり、その都度新たに全てのハードウェア、ソフトウェアを作り直す必要があるという問題点があった。
【０００４】
さらに、種々の制御を行うためにＲＯＭの中に書き込まれた制御ソフトがアセンブラ言語で表現されているため、そのプログラムの内容及び作成手法は専門家にしか解読できないような、いわば属人的なものであった。そのため、特に、実際のアプリケーションソフトの作成段階において、最初のプログラマー以外の者には、ソフトウェア内容の詳細が理解できないのみならず、別の機能のソフトを追加する場合には、始めから全部作成し直す必要があった。
【０００５】
本発明は、このような問題に鑑みてなされたもので、その目的は、シングルチップマイコンを用いた場合でも、入出力信号数の増加や機能の追加を容易にし、しかも、制御ユニットのプログラム変更を容易にする自動車用制御ユニットを提供することにある。
【０００６】
【課題を解決するための手段】
前記目的を達成するために、本発明に係わる自動変速機制御ユニットは、基本的には、スロットル開度を検出するセンサからの情報、空気流量を検出するセンサからの情報、水温を検出するセンサからの情報のうちの何れか１つ以上の情報が入力される入力部と、自動変速機の油圧を制御するアクチュエータ、変速位置を制御するソレノイドのうちの何れか１つ以上のアクチュエータを制御する信号を出力する出力部と、前記アクチュエータを制御して自動変速機を制御するためのプログラムが格納されたメモリと、前記プログラムを演算実行する中央演算処理部と、を備え、前記プログラムは、インターフェースソフト及びアプリケーションソフトを有し、前記アプリケーションソフトは、前記アクチュエータを制御する演算を行うための機能を有し、前記インターフェースソフトは、前記アプリケーションソフトと前記入力部との間の信号を授受する演算を行うための機能を有し、前記インターフェースソフトから前記アプリケーションソフトへの信号の授受は、関数を用いて行なわれ、前記メモリ及び中央演算処理部はシングルチップマイコンとして構成されることを特徴とし、入出力点数の増加や機能の追加に即対応可能な制御ユニットの構成とした。
【０００７】
【作用】
このように構成された本発明によれば、自動車制御にシングルチップマイコンを用いた場合でも、入出力点数の増加や機能の追加に対する対応が容易になり、インターフェースソフトの書換えのみでアプリケーションソフトが永続的に使え、更にコアユニットの作り換えが不必要となるため、プログラムを含めた制御ユニットの開発を容易にすることができる。
【０００８】
【実施例】
以下、本発明の実施例を図面に基づき詳細に説明する。なお、以下の実施例を説明するための図において、同一機能を有するものは同一符号を付し、その繰り返しの説明は省略する。
図１、２に本発明に係わる自動車用制御ユニットの一実施例を示す。
【０００９】
図１にコアユニット１の概略の一例を示す。コアユニット１は、アプリケーションソフトとＯＳ（Operating System）を接続するインターフェースソフトが、第１のメモリである内部ＲＯＭ２に内蔵されたインターフェースソフト記憶手段、前記アプリケーションソフトとインターフェースソフトを演算実行する中央演算処理装置（ＣＰＵ）３、演算結果等をメモリする第２のメモリであるＲＡＭ（書換え可能なメモリ）４及び制御ユニット拡張用のＩ／Ｏ（Input/Output）、メモリ等をバスあるいはＬＡＮ等を介して通信する拡張手段５から構成されている。
【００１０】
内部ＲＯＭ２内のインターフェースソフトは、割込み処理、タスクディスパッチャ、デバッグ機能、学習制御等の自動マッチング機能、ポート割付機能及び標準自動車Ｉ／Ｏ処理等（後述する）が含まれている。また、内部ＲＯＭ２には自動車メーカ等で作成するアプリケーションソフトも書き込むことができる。拡張手段５は入出力点数の増加や機能の追加に伴う外付けのＩ／Ｏ（後述する）、ＲＯＭ等のためのものである。
【００１１】
図２は拡張した場合のユニット構成図の一例である。図２において、図１で示したコアユニット１の拡張手段５に、バスあるいはＬＡＮ（Local Arear Network ）等の通信線を介して自動車用拡張Ｉ／Ｏ６及び外付けＲＯＭ７が付加的に連結されている。この拡張Ｉ／Ｏ６には、ソフトウェア的タイマあるいはハードウェア的タイマが存在する。そして、ハードウェア的タイマは、例えば点火時期制御や燃料制御のように、時間を精密に合わせる場合等の高精度制御に用いられ、ソフトウェアタイマはメータのようなラフな制御に用いることができる。また、前記拡張Ｉ／Ｏ６は、例えばプログラム可能な入出力装置であり、コアユニット１内のＣＰＵ３でデータをレジスタに書き込み、パルス幅変調（ＰＷＭ：Pulse Width Modulation）等の信号を出力することが可能なものである。なお、内部ＲＯＭ、外付けＲＯＭは電気的に書換え可能なメモリ（フラッシュメモリ、ＥＥＰＲＯＭ）を用いることもできる。
【００１２】
このようにして、図１に示したコアユニット１のバージョンが例えば４気筒エンジンに対応したものであって、次に、例えば６気筒エンジンに対応すべく制御を増加させる場合には、外付けＲＯＭ７に制御内容を入力し、かつ、増加した制御量を拡張Ｉ／Ｏ６を介してアクチュエータ（図示せず）に信号を出力するようになっている。
【００１３】
次に、図３、４に本発明の他の実施例を示す。
図３は拡張なしの場合の具体的ユニット構成図の一例である。図３において、拡張なしの場合は、コアユニット１がそのまま標準ユニット８となる。拡張手段５はＩ／Ｏポートの一部であり、したがって、拡張手段５も、センサＡ、Ｂ及びアクチュエータＡ、Ｂ等のＩ／Ｏポートとして使用できる。また、制御ユニット９はコアユニット１、センサ信号の処理を行うHard Filter１０及びアクチュエータ信号の増幅を行うパワー回路１１から成る。
【００１４】
図４は拡張あり場合の具体的ユニット構成図の一例である。図４において、拡張した場合は、コアユニット１の拡張手段５がコントロールバス、アドレスバス及びデータバスとして用いられる。上記３つのバスによって自動車用拡張Ｉ／Ｏ６及び外付けＲＯＭ７がコアユニット１と接続され、標準ユニット１２が構成されている。この場合、Ｉ／Ｏポートとして用いていた拡張手段５が拡張用に使用されるため、センサＡ、Ｂ及びアクチュエータＡ、ＢのＩ／Ｏポートがなくなってしまう。そこで、拡張Ｉ／Ｏ６は上記コアユニット１で減った分のＩ／Ｏポートの数を含めたポート数とする必要がある。ここで、一例として、センサＣ、Ｄ及びアクチュエータＣが増えたとすると、上記３つのポートとセンサＡ、Ｂ及びアクチュエータＡ、Ｂを加えたＩ／Ｏポート数が用意されることになる。制御ユニット１３は、標準ユニット１２、センサＣ、Ｄ及びアクチュエータＣ用のHardFilter１４及びパワー回路１５、センサＡ、Ｂ及びアクチュエータＡ、Ｂ用のHard Filter１０及びパワー回路１１から構成される。
【００１５】
図５はコアユニット１自体の拡張構成図の一例である。コアユニット１内には、ＣＰＵ３、内部ＲＯＭ２、ＲＡＭ４、拡張手段５を含んだＩ／Ｏ１６、Ａ／Ｄ１７、タイマ１８、自動車用拡張Ｉ／Ｏ６及び外付けＲＯＭ７等の外部メモリからアクセスを高速に実行するためのキャッシュメモリ１９が設けられている。すなわち、このキャッシュメモリ１９は、次に読み込まれる外付けＲＯＭ７からのデータを予めメモリさせるもので、ＣＰＵ３はわざわざ外付けＲＯＭ７までアクセスしなくても、キャッシュメモリ１９から次に読み込まれるデータにアクセスすることができるため、外付けＲＯＭ７の内容を読み込むのに要する時間を節約することができ、応答性を向上させることができる。また、これらは全てバス２０で接続される。
【００１６】
図６〜８は各仕様に応じた拡張構成図の一例を示す。
図６は、例えば４又は６気筒エンジンに用いる場合の標準ユニット構成の例である。図６において、適用対象車における制御対象が４又は６気筒エンジン制御のみである場合には、制御項目やＩ／Ｏ数等がさほど多くないため、コアユニット１のみで対応することができ、コアユニット１がそのまま標準ユニットとなる。この場合、内部ＲＯＭ２にアプリケーションソフトとインターフェースソフトを書き込んで制御を行う。
【００１７】
図７は、図６の構成に故障診断を加えた６気筒エンジン、あるいは自動変速機制御を加えた６気筒エンジンの場合の標準ユニット構成の一例を示す。図７において、適用対象車が故障診断を加えた６気筒エンジン、あるいは自動変速機制御を加えた６気筒エンジンの場合は、コアユニット１に自動車用拡張Ｉ／Ｏ２１及び外付けＲＯＭ７（ａ）を拡張して設け（拡張部１）、当該６気筒エンジンの仕様で必要なポート数の確保、並びに、制御項目増加に伴うメモリの確保を行う。この場合、ソフトは、追加分を外付けＲＯＭ７（ａ）に記憶させるか、あるいは内部ＲＯＭ２にインターフェースソフトを、外付けＲＯＭ７（ａ）にアプリケーションソフトを記憶させることもできる。
【００１８】
図８に６気筒統合制御を行う場合の標準ユニット構成の一例を示す。適用対象車が、例えば、故障診断、自動変速機、定速走行制御、計器類等のインパネ制御などの多数の制御を付加した６気筒エンジンを搭載した車両、すなわち６気筒統合制御の追加機能を増大させた車両の場合には、図８に示すように、図７の構成に加え、更に拡張Ｉ／Ｏ２２及び外付けＲＯＭ７を拡張して対処する（拡張部２）。なお、図８の場合も図７と同様に、外付けＲＯＭ７及び７（ａ）が拡張された場合は、追加分を外付けＲＯＭ７，７（ａ）に記憶させるか、あるいは内部ＲＯＭ２にインターフェースソフトを、外付けＲＯＭ７（ａ）及び外付けＲＯＭ７にアプリケーションソフトを記憶させることができる。後者の場合は、インターフェースソフトとアプリケーションソフトが分離されているため、アプリケーションソフトのデバッグが容易になる。
【００１９】
このように、入出力点数の増加やソフトを含めた機能の追加に対してすぐに対処できることもコアユニット１と拡張手段５の特徴である。
図９はコアユニットを用いた場合のエンジンＡＴ（Automatic Transmission）制御ユニット構成図の一例である。図９において、コアユニット１内の内部ＲＯＭ２には、エンジン及びＡＴ制御で高速演算が必要なアプリケーションソフト（例えば、点火燃料制御等のハード的割り込み処理）とインターフェースソフトが書き込まれている。また、コアユニット１には、Ａ／Ｄ１７の有効利用のため、複数のアナログ信号を状況に応じて選択するマルチプレクサ（ＭＰＸ）２３が備えられており、スロットル開度ＴＶＯ、空気流量信号Ｑａ、水温Ｔｗ等の信号処理を行う。さらには、スイッチ信号（アイドルＳＷ）及び車速Ｖｓｐ等のパルス信号が入力される。コアユニット１でのＡＴ制御の出力信号として、変速機の油圧を制御するライン圧ＰＬ、変速位置を制御するソレノイド信号ｓｏｌＡ、ｓｏｌＢが出力される。また、エンジン制御はタイマを数多く用いるのでエンジン制御用拡張Ｉ／Ｏ２４が必要となる。エンジン制御用拡張Ｉ／Ｏ２４は、多くのタイマを内蔵したものである。そこで、エンジンの回転信号ＰＯＳ及び気筒判別信号ＲＥＦを拡張Ｉ／Ｏ２４に入力し、燃料噴射量ＩＮＪ、点火時期ＩＧＮ、アイドル制御ＩＳＣを出力する。また、外部ＲＯＭ７にはエンジンＡＴ制御の低速演算で十分なアプリケーションソフト（例えば、変速点制御、ロックアップ制御）を書き込むようにする。
【００２０】
図１０はコアユニットを用いた場合のＡＢＳ（Antiskid Brake System ）トラクション制御ユニット構成図の一例である。コアユニット１内の内部ＲＯＭ２にはＡＢＳ制御用のアプリケーションソフトと、ＡＢＳ制御とトラクション制御で必要なインターフェースソフトが書き込まれている。また、Ａ／Ｄ１７の有効利用のため、複数のアナログ信号を状況に応じて選択するＭＰＸ（マルチプレクサ）２３が備えられており、自動車の絶対車速を求めるためのＧ（加速度）センサ等の信号処理を行う。さらに、駆動輪側の速度である車速Ｖｓｐ、非駆動輪側の速度である車輪速（右前）及び車輪速（左前）等のパルス信号が入力される。また、コアユニット１でのＡＢＳ制御の出力信号として、ブレーキ圧を制御するＰＷＭ信号Ｄｏｕｔが出力される。また、トラクション制御の機能を付加する場合は、トラクション制御用拡張Ｉ／Ｏ２５を用いて、エンジントルクを低減するためのスロットル開度、点火時期リタード量を出力する。また、外部ＲＯＭ７にはトラクション制御のアプリケーションソフトを書き込むようにする。このように、本図示例では、ＡＢＳ制御のユニットを作成して標準化を行い、それに拡張してトラクション制御を行うようにしたものである。
【００２１】
次に、制御ユニット間をＬＡＮ（Local Area Network）で連結させた場合の実施例について説明する。
図１１は、エンジンＡＴ制御ユニット及びＡＢＳトラクション制御ユニットの両方のユニットを使用する車両において、両ユニットをＬＡＮで連結させた場合のシステム構成図の一例である。図７、図８で示したエンジンＡＴ制御ユニット２７、ＡＢＳトラクション制御ユニット２８等がＬＡＮ（データ通信線）２６で連結されている。ＬＡＮ２６と制御ユニット２７のバス１２９は通信コネクタ１３０、通信回路１３１でデータ通信を行う。また、ＬＡＮ２６と制御ユニット２８のバス１３２は通信コネクタ１３３、通信回路１３４でデータ通信を行う。例えば、エンジンＡＴ制御ユニット２７で演算したエンジントルク等のデータをＡＢＳトラクション制御ユニット２８に送信し、車輪空転時のエンジントルク低減制御（スロットル開度減少，点火時期リタード及び燃料量減少等）をエンジントルクフィードバックで実行し制御精度を向上させる。
【００２２】
図１２は演算ユニット３３とＩ／Ｏユニット３２とを分割し、これら相互間をＬＡＮ１２６で通信した場合の構成図の一例である。Ｉ／Ｏユニット３２はＣＰＵ３、内部ＲＯＭ２、ＲＡＭ４、拡張手段５を含んだＩ／Ｏ１６、Ａ／Ｄ１７、タイマ１８、ＭＰＸ２３及びエンジンＡＴ制御用拡張Ｉ／Ｏ１２４から成る。Ｉ／Ｏユニット３２ではセンサから入力された信号をフィルタ処理，Ａ／Ｄ変換処理等を実行し、その処理データをＬＡＮ１２６を介して演算ユニット３３に送信する。そして、エンジンＡＴ演算ユニット３３では送信されたデータを用いて燃料噴射幅ＩＮＪ、点火時期ＩＧＮ、アイドル制御量ＩＳＣ、変速機のライン圧ＰＬ等が演算され、その演算結果をＬＡＮ１２６を介してＩ／Ｏユニット３２に送信する。そして、インターフェースソフトを含むコアユニット１内のＩ／Ｏ１６及びエンジンＡＴ制御用拡張Ｉ／Ｏ１２４より上記出力信号が出力される。この場合、演算ユニット３３はＩ／Ｏユニット３２と同じコアユニット１を用いているため、同様の機能を持っている。しかし、演算ユニット３３の内部ＲＯＭ２には演算で用いるアプリケーションソフトのみが書き込まれている。ＬＡＮ１２６とユニット３２、３３との通信はそれぞれ通信コネクタ１３６，１３９、通信回路１３７，１４０で実行する。また、上記通信コネクタ１３６，１３９、通信回路１３７，１４０は各制御ユニットのＣＰＵの命令で動作する。
【００２３】
このように、本図示例では、インターフェースソフトというＩ／Ｏ処理ソフトを内部ＲＯＭ２に書き込み、一つのユニットでＩ／Ｏユニット３２を構成したものであり、したがって、例えばＡＢＳトラクション制御ユニットやエンジンＡＴ制御ユニット等に入力される、同じ信号（オーバーラップ信号）をＩ／Ｏユニット３２に一本化して入力することができ、Ｉ／Ｏの共用化を図り、部品点数の削減を可能とする。
【００２４】
以下、前述のインターフェースソフトの概略を実施例により説明する。
前述したように、インターフェースソフトとは、ＯＳとアプリケーションソフトとの仲介をなすソフトである。そのため、アプリケーションソフト提供メーカはＯＳを考慮することなくアプリケーションソフトを作成することができ、ソフト開発が容易になる。
【００２５】
図１３から図１７に制御ユニットによる入力信号処理の比較を示す。
図１３及び図１４は従来の空気流量センサ信号の処理構成である。図１３は空気流量Ｑａを検出及び演算する際にホットワイヤ（ＨＷ）式空気流量計を用いた場合である。上記空気流量計の信号は、まず 制御ユニット３８に設けられたハードフィルタ１３８で信号のノイズ除去を行い、シングルチップマイコン１４０のＡ／Ｄ変換器２４０に入力される。そして、Ａ／Ｄ変換器２４０で変換された信号は関数Ａ４０で空気流量Ｑａに変換される。また、図１４のように吸気管内圧力計を用いた場合は、制御ユニット３９に設けられたホットワイヤ（ＨＷ）式空気流量計とは異なるハードフィルタ１３９で信号のノイズ除去を行い、シングルチップマイコン１４１のＡ／Ｄ変換器２４１に入力される。そして、Ａ／Ｄ変換器２４１で変換された信号は関数Ｂ４１で空気流量Ｑａに変換される。
【００２６】
図１５はインターフェースソフト内蔵の内部ＲＯＭ１４３を搭載した標準ユニット４２の入力信号処理構成の一例である。標準ユニット４２を用いた場合は、図１３及び１４で示した吸気管内圧力計あるいはＨＷ式空気流量計のいずれのセンサにも対応可能となる。つまり、内部ＲＯＭ１４３のインターフェースソフトが上記２つのセンサのフィルタリング及び関数処理を実行するからである。まず、入力される信号は標準ユニット４２のＡ／Ｄ変換器１４２でディジタル化され、内部ＲＯＭ１４３のインターフェースソフトによる処理が行われる。次に、上記ハードフィルタ１３８，１３９の代わりにディジタルフィルタ２４３を用い、ソフト的にそれぞれのセンサ信号に対応したカットオフ周波数を設定するようにしておく。更に、各センサ信号によって異なる特性を持つ関数の代わりに高次関数４３（Ｑａ＝ΣＫｉ＊Ｖ Ｋｉ：次数，Ｖ：ディジタル化した電圧信号）を用いて各信号に対応した次数Ｋｉを設定し、それぞれに対応した関数を作り、演算して空気量Ｑａの算出を行う。これにより各種のセンサ信号入力をソフト的に切り替えることが可能となる。すなわち、インターフェースソフトにより、前記関数Ａ及びＢの特性を高次関数４３で作出することができ、Ｑａは同一のポートでどのような方式でも算出することができる。
【００２７】
図１６は可変式ハードフィルタを用いた入力信号処理構成の一例である。制御ユニット１４４には、センサ信号の種類によって可変抵抗等を変化させるとともに、カットオフ周波数を変えて信号に対応したフィルタリングを実行する可変式ハードフィルタ４４、Ａ／Ｄ変換器１４７、インターフェースソフト（関数Ａ，Ｂ等）から成る標準ユニット２４４が設けられている。まず、入力される信号を上記可変式ハードフィルタ４４でノイズ除去を実行し、標準ユニット２４４に入力する。そして、標準ユニット２４４内にそれぞれのセンサ信号に対応した関数、例えばＨＷ式空気流量計式なら関数Ａ４５、吸気管内圧力計式ならば関数Ｂ４６というような演算関数が備えられており、セレクタ４７により入力センサ信号に対応した関数を選択して空気量Ｑａが算出される。
【００２８】
図１７は使用センサ分にハードフィルタを備えた入力信号処理構成の一例である。制御ユニット１４８において、各種のセンサ（ＨＷ式空気流量計，吸気管内圧力計）に対する入力端子及びそれぞれに固有のハードフィルタ４８，４９を備えておき、標準ユニット１４９内に備えた関数Ａ４５，関数Ｂ４６，セレクタ４７により空気量Ｑａを算出する。
【００２９】
図１８はインターフェースソフトによるポート割当機能の一例を示す概略図である。図１８（ａ）は標準ユニット５０を用いたＨＷ式空気流量計式の６気筒エンジン制御、図１８（ｂ）は吸気管内圧力計式の４気筒エンジン制御の入出力ポート割当構成の一例を示す。
図１８（ａ）の場合、ＨＷ式空気流量信号Ｑａ，エンジン回転数信号Ｎｅ，水温信号Ｔｗ，酸素センサ信号Ｏ２等の信号が入力ポート、また、６気筒分の燃料噴射信号ＩＮＪ，ＤＩＳＴ（Distributor ）方式の点火信号ＩＧＮ及びＩＳＣ（Idle Speed Control）等の信号が出力ポートとして割り当てられる。この標準ユニット５０を図１８（ｂ）仕様の４気筒エンジンに用いる場合は、ＩＮＪパルス信号が６気筒の６本から４気筒の４本に減少するため、２本のポートが余る。しかし、吸気管内圧力計を使用するエンジン制御では、空気流量を演算する際、吸気温補正、排圧補正が必要となる。そこで、出力ポートで余った２本を上記吸気温及び排圧の入力ポートとして用いれば有効な標準ユニット５０使用が実現できる。なお、図１８（ｂ）では、空気流量信号Ｑａに代えて、吸気管内圧力信号Ｐｍが入力ポートに割り当てられている。このような、ポート割当機能を標準ユニット５０のインターフェースソフトに持たせることによりユニットの有効利用が実現できる。また上記吸気温及び排圧の信号取り込みに関しては、マルチプレクサ等を標準ユニット５０との間にハード的に組み込み、切り替えることで柔軟性を持たせる。このようにエンジン仕様及びセンサ仕様が違った場合でもインターフェースソフトのポート割当機能により効率の良い入出力信号変更が可能になる。
【００３０】
図１９はインターフェースソフトによる入力信号の組み合わせ処理の構成図の一例である。組み合わせ処理とは、センサ等からの入力信号の組み合わせにより別の信号を生成する処理であり、この処理をインターフェースソフト５７で実行する。例えば、エンジン回転５１と車速５２から処理Ａを介してギヤ比信号５３を、また、エンジン回転５１とタービン回転５４から処理Ｂを介してタービントルク５５及び出力軸トルク５６を演算する。このような処理機能をインターフェースソフト５７に持たせることにより、ユーザーつまりアプリケーションソフト開発側がＲＡＭの各アドレスに格納された、前記ギヤ比信号等のデータにアクセスすれば、何時でも自由にその内容をみることが可能となる。このような組み合わせ処理の実行により、今後の制御項目増大による必要パラメータの増加が生じた場合でも新たなセンサの追加なしで対応が可能となる。
【００３１】
図２０はインターフェースソフトによるセンサ入力時の演算処理機能の一例を示す。現状のエンジン制御では、空気量センサ，水温センサ，スロットル開度センサ及びクランク角センサの信号Ａ／Ｄ変換あるいはパルス数計測等の信号処理を施した値が直接アプリケーションソフトで用いられるわけではない。例えば、空気量センサからの信号は、一度テーブルを参照し補間計算を施して、初めてアプリケーションソフトで使用可能な吸入空気量指数ＱＡを求めることができる。このように、アプリケーションソフトで必要な信号、すなわち吸入空気量指数ＱＡ，吸入空気量定数ＱＳ，水温ＴＷＮ，水温格子検索用ＴＷＫ，スロットル開度ＡＤＴＶＯ，ＴＶＯ１Ｓ及びエンジン回転数ＬＮＲＰＭ，ＨＮＲＰＭ，ＭＮＲＰＭの演算をインターフェースソフト５８に設けておくことによりソフト開発が容易になる。また、前記吸入空気量指数ＱＡ，吸入空気量定数ＱＳ，水温ＴＷＮ，水温格子検索用ＴＷＫ，スロットル開度ＡＤＴＶＯ，ＴＶＯ１Ｓ及びエンジン回転数ＬＮＲＰＭ，ＨＮＲＰＭ，ＭＮＲＰＭの各データをＲＡＭに格納しておくことにより、これらアプリケーションのデータは、ＲＡＭにアクセスすれば何時でもみることができる。
【００３２】
次に、インターフェースソフトの記述方法、つまりソースリストのフローの実施例を示す。
図２１はインターフェースソフトによる時間割付の一例を示す概略図である。自動車制御にはさまざまなタイミングで起動する各制御のタスク及びサブルーチンがあり、それぞれがある一定周期で動作している。Ｃ言語記述では時間管理及びタイミング割付が困難であるため、自動的割当て機能をインターフェースソフトにもたせた。エンジン制御アプリケーションソフトにはクランク角度割り込み、点火パルス発生、インターバル割り込み、エンジン回転数取り込み処理といった各種の起動タスクが存在しており、それぞれが固有の要求タイミングを持ち、それに見合った回転または時間周期で起動している。また他のＡＴ制御やＡＢＳ制御アプリケーションソフトに対しても同様である。このようにさまざまな要求タイミングがある各アプリケーションソフト及び内部の各タスクをインターフェースソフトの自動的割当て処理機能においてそれぞれの要求タイミングを判断してマイコンの起動周期設定に必要なタイマ等の初期設定さらに要求タイミングでの処理内容としてベクタアドレスの割付を自動的に行うようにしている。
【００３３】
図２２は図２１の詳細な制御フローチャートの一例である。たとえばＣ言語記述アプリケーションソフトにおいて、タスク起動タイミングの記述形式を例としてＪＯＢ＝要求タイミングとした場合に、ＪＯＢの内容が何であるかを各起動タスクごとに判別プログラムを動作させ、ＪＯＢ＝Ａ（５９）ならマイコンへ２ｍｓ周期処理タイミングの初期設定を行い、さらに２ｍｓ周期処理としてベクタアドレスの割付６０をする。ＪＯＢ＝Ｂ（６１）なら上記と同様にマイコンへ４ｍｓ周期処理タイミングの初期設定を行い、また４ｍｓ周期処理としてベクタアドレスの割付６２を行い、ＪＯＢ＝ＲＥＦ（６５）ならば回転周期処理の初期設定をマイコンに行い、起動タスクのベクタアドレスを割り付ける（６６）。また、ＪＯＢ＝Ｘ（６３）ならばユーザが要求した独自のタイミングたとえば２０ｍｓ周期とするとそれに応じたマイコンへの初期設定及びベクタアドレスの割付６４を行うようにしている。このような機能をインターフェースソフトに持たせておくことで自動車制御ソフトがＣ言語記述に移行した際の時間管理及びタイミング割付の問題を回避することができる。
【００３４】
図２３はインターフェースソフトによる割り込みレベル割付のフローチャートの一例である。基本的には時間割付のフローと同様に、各制御内の起動タスクからの要求割り込みレベルのラベルが何であるか判別して、そのラベルに応じて優先順位を各タスクへ割当て、マイコンへの優先順位の初期設定を自動的に行うようにしている。要求レベルがＬ７かを判断６７し、ｙｅｓならば各対象ＪＯＢを割り込みレベル７として優先順位設定６８を行う。以下同様に、要求レベルを判別（６９，７１，７３）し、各レベル設定（７０，７２，７４）を行う。各制御アプリケーションソフトにおいて、数多くのタスクが個々のタイミングで起動する中で、各タスクの割り込みレベルの設定は、リアルタイム性が重視される自動車制御では重要な役割をもち、Ｃ言語記述化を図った場合には不可能な割り込みレベルの記述が可能となる。
【００３５】
表１はタイミング及び優先順位割付のためのＣ言語記述仕様である。自動車制御に必要な大体のタスク起動タイミングをピックアップして予め仕様化しておき、それを各制御のソフトを開発するときにタスクに要求するタイミング及び優先順位を仕様の中から選択し、タスクの先頭に例えば２ｍｓ周期のタスクで優先順位７ならばラベルＡ，Ｌ７を、４ｍｓ周期のタスクで優先順位５ならばラベルＢ，Ｌ５を記述すればよい。また回転周期のラベルも数個設けておく。さらに、ユーザ（アプリケーションソフト開発側）設定用のラベルも備えることで要求タイミングを自由に設定できる。このように、アプリケーションソフトはそのままで、インターフェースソフトにおいてマイコンへの初期設定値の決定及び割付を行うこと、つまりインターフェースソフトの改良を行うだけで各種マイコン（ＣＰＵ）への対応が容易に行うことができる。
【００３６】
【表１】
さらに、インターフェースソフトの処理機能として対応マイコンで最適と考えられる入出力ポートの割付けを行う。標準ユニットを用いて制御対象の異なった自動車制御を行う場合には、入出力ポートは標準ユニットにより数が限られており、４気筒と６気筒の制御には別々の入出力ポートの割当てが要求される。そのため、最適入出力ポートの割当てのパターンを設定しておき、自動車制御ソフトが、どのタイプを制御しようとしているかを判断してポート割当てのパターンを自動的に選択し、マイコンへの入出力信号を決定するようにする。制御対象に対応した最適な入出力ポートの割当てをそれぞれパターン化して備えておく。
【００３８】
図２４は最適入出力ポート割当のパターン決定のフローチャートの一例である。まず、制御対象が４気筒エンジン制御ならば、次に空気量測定の方式を判別して空気流量計式ならばパターンＡを、吸気管内圧力計式ならばパターンＢを割当て、６気筒エンジンの制御においてもパターンＣ，パターンＤ等をそれぞれの測定方式のタイプを判別し、それに応じて割当てを行う。これにより共通ユニットを用いての有限である入出力ポートの割当てをパターン化することで、自動的に制御対象に対応した割当てが可能となる。
【００３９】
図２５はＲＡＭ領域内における多用データ一括集団配置の一例である。ＲＡＭ領域には独自開発されたエンジン，ＡＴ，ＡＢＳ制御用のデータがそれぞれ確保されるが、その中で２つ以上の制御内で使われる使用頻度の高いデータを多用データとして集団配置する。これによりベースレジスタを活用することでプログラムのＲＯＭ容量を減らすことができる。また、各制御アプリケーションソフト間同志での通信いわゆるデータ提供を行うにしても多用データとして一括配置しておいた方が１ブロックでデータ参照が可能となる。
【００４０】
図２６は多用データ一括配置のフローチャートの一例である。独自に開発されたエンジン制御、ＡＴ制御、ＡＢＳ制御のＣ言語記述アプリケーションソフトを用いて、その流れを説明する。図２６において、まず、エンジン制御に使用するために宣言された変数が宣言の順番にＲＡＭ領域に割り付けられる７５。ここでＲＡＭ領域内の多用データ割当て領域の先頭アドレスを＃ＡＤＤとしておき、ＡＴ制御で宣言されている変数にエンジン制御変数と同一変数がないか検索７６する。同一変数が見つかればそのデータをＡＤＤ番地に格納し、アドレスＡＤＤをインクリメントする。すべてのＡＴ制御の宣言変数をエンジン制御変数と照らし合わせ終わるまで繰り返す。
【００４１】
ＡＴ制御変数中を検索終了後７７、次に、ＡＢＳ制御において宣言した変数についてエンジン制御及びＡＴ制御変数に同一変数がないか検索７８を行い、見つかれば、まず多用データ割当て領域にすでに多用データとして配置されていないかを判別し、なければＡＤＤ番地にそのデータを格納して、上記と同様にＡＤＤをインクリメントしながら全ての変数の照合が終了するまで繰り返す。
【００４２】
このような手順を経ることにより、ＲＡＭ領域内に多用データとして一括して配置することが可能となる。また、エンジン制御だけをみても数多くの起動タスクから構成されており、各タスクにおいて数個の使用変数が宣言されている。このように、１つの制御中にも使用頻度の高いデータが多く含まれている可能性があり、同様の簡単なフロー構成を用いることにより、制御間のみならず各制御内のタスク間における多用データの探索及び一括配置をも行うことができる。
【００４３】
次に、監視プログラムにより異常な制御箇所を発見するための一実施例について説明する。
図２７は監視プログラムを利用した異常箇所発見のフローチャートの概略図の一例である。図２７において、自動車制御の各制御部並びに各タスクには、特有のエラーコードが設定してある。監視プログラムは、エラーコードが発生した時にコード識別により、エンジン制御部か、ＡＴ制御部か、あるいはＡＢＳ制御部かを判別して、それぞれの制御部に設定されたフェール対策を起動するようにしてフェールセーフを行う。また、このようなエラーコードを各制御部とその中の各タスクに設定しておくことにより、１つにした自動車制御の膨大なアプリケーションソフトのデバッグを行う際に、エラーコードを識別すれば、どの制御アプリケーションソフトにおける、どのタスクにおいて異常が発生したか等のバグ要因の発見を容易に行うことが可能となる。
【００４４】
さらに、インターフェースソフトにおいて独自開発した各制御アプリケーションソフトの各々のタスクには、タスク起動時に起動フラグをたてるフラグ操作プログラムが付設されている。また、インターフェースソフトには、フラグ操作プログラムによる起動フラグをある一定周期で監視する監視プログラムが設けられている。この監視プログラムは、各タスクの処理時間を演算及び管理を行うとともに、ＣＰＵ負荷率の診断をも行う。そうして監視プログラム内に設定された各タスクの規定処理時間内にタスク処理が終了しなかったり、あるいは各制御に割り当てられたＣＰＵ負荷率を越えた場合に、予め設定された識別可能なエラーコードを出力させてフェールセーフ対策やデバッグ処理に活用する。 監視プログラムを利用して異常箇所を発見するための手法としては、例えば、ソフトウェアタイマを引用したフェールセーフソフト、監視内容を拡張した起動タスク監視プログラム、ウォッチドッグタイマを用いたマクロ処理時間監視の方式などが考えられる。
【００４５】
前記ソフトウェアタイマを引用したフェールセーフソフトは、たとえば、その処理時間監視タスクにおいて、複数のタスクを優先順位が高い順に並べておき、実行中のタスクの処理時間監視用のタイマをインクリメントする動作を行い、次に実行中のタスクが規定の処理時間内に終了しているかを調べるもので、予め設定しておいた規定処理時間とタイマのデータを比較して、規定時間を超過していれば各タスク特有のエラーコードを出力するようにしたものである。なお、前記規定処理時間は監視プログラムの起動周期をもとにしてその整数倍で決まるため、起動周期を可変させることにより何ｍｓにでも設定することができる。
【００４６】
監視内容を拡張した起動タスク監視プログラムは、たとえば、１つのソフト上に各制御のプログラムがあり、それらのタスクを実行した際に監視プログラムが実行タスクの処理時間の演算及び管理、並びに各制御によるＣＰＵ負荷率の監視を行えるようにしたものである。この起動タスク監視プログラムには、例えばエンジン制御、ＡＴ制御、共通制御等の各制御によるＣＰＵ負荷率を監視するためのプログラムが備えられている。このプログラムは、ＣＰＵに対する各制御の負荷をカウントし、ＣＰＵ負荷率の過占有として各制御関係のタスク（仕事）が全体の７０％を越えるとエラーとするような負荷率エラーの取り決めを行っておき、各制御部に用意されたカウンタが７０以上かを診断して、異常があればその制御部中の各タスクの優先順位の高いほうから処理時間を診断し、異常タスクを指すエラーコードを出力する。負荷率エラーが発生しなくてもＣＰＵ負荷率は、ＥＮＧＩＮＥ，ＡＴ，ＣＯＭＭＯＮ等の各制御部のカウンタから知ることができる。
【００４７】
ウォッチドッグタイマを用いたマクロ処理時間監視の方式は、たとえば、処理に異常が生じてウォッチドッグタイマのオーバーフロー設定時間内にタイマがクリアされないと、オーバーフローにより強制割り込み（ＮＭＩ）が発生して監視プログラムが動きだし、異常発生の直前のスタックポインタ（ＳＰ）をもとに各プログラムの格納されているアドレスとで比較し、異常発生のタスクを指すエラーコードを出力するものである。このように、ウォッチドッグタイマ方式は、プログラム規模は小さくて済むが、各タスクの状態を大雑把にしか監視できない。しかし、バグの発生しにくさではウォッチドッグタイマ方式の方が望ましい。
【００４８】
次に、インターフェースソフトに記述されるリストに係わる実施例について説明する。
図２８はインターフェースソフトに基本処理プログラムの組み込み関数化の一構成例である。エンジン回転取り込み９０，車速演算９１，タービン回転数９２，スロットル開度取り込みプログラム９３及びさまざまな周波数で使用される各フィルタの演算プログラム９４を関数化し、さらにＬＡＮ等の通信用の組み込みソフト９５も関数化してインターフェースソフトに持たせた。
【００４９】
図２９は一般的自動車制御用変数の定義及び宣言の関数化の一例である。膨大なフラグ変数や入出力信号等のＩ／Ｏ変数をインターフェースソフトに定義及び宣言してヘッダファイルとして関数化させる。フラグ変数等は最適Ｃ言語となるように、型宣言さらにビットフィールドを考慮して定義しておく。
図３０は組み込み関数の仕様の一例である。仕様化しておくことで制御ソフト開発側がヘッダファイルをインクルードし、定義済みの変数を利用して制御を構成することができ、また制御工程で信号取り込みや演算が生じた場合には、先に述べた基本処理関数の中から必要な処理関数を呼び出すようにすれば良い。これらの基本処理プログラムの関数化，一般的自動車制御用のＩ／Ｏ，変数を定義したヘッダファイルの関数化により、自動車制御ソフトの開発を簡略化することができる。すなわち、Ｉ／Ｏ処理等によりソフトウェアを標準化し、それを仕様書としてアプリケーションソフト開発側（ユーザー）に提示すれば、ユーザー側は、その仕様書を基に必要な機能ソフトをサブルーチン等により追加または変更することができ、機能アップを図ることができる。
【００５０】
図３１は基本処理関数の処理選択機能の手段の一例である。各制御のアプリケーションソフトからの基本処理関数の呼出しをする時に、引数により処理条件を選択する例を示す。例えば、エンジン回転取り込み関数には、回転数演算方式や取り込みサンプリング時間さらにパルス測定センサに関しても各種の手段が存在する。これらの手段に対応したプログラムをインターフェースソフトに持たせておき、開発側が引数により手段を選択し、これを記述することで開発側の要求を達成することができ、基本処理関数の汎用性が向上する。同様に、フィルタの演算においても引数にフィルタタイプ，カットオフ周波数，次数等をわたせばそれに対応したフィルタを設定できる。
【００５１】
以上、本発明の実施例を詳述したが、本発明は、前記実施例に限定されるものではなく、特許請求の範囲に記載された本発明を逸脱することなく種々の設計変更を行うことが可能である。
【００５２】
【発明の効果】
以上の説明から理解されるように、本発明によれば、自動車制御にシングルチップマイコンを用いた場合でも、入出力点数の増加や機能の追加に対する対応が容易になり、インターフェースソフトの書換えのみでアプリケーションソフトが永続的に使用可能となり、しかも、コアユニットの作り換えが不必要となるため、プログラムを含めた制御ユニットの開発が容易になる。
【図面の簡単な説明】
【図１】コアユニットの概略図。
【図２】拡張した場合のユニット構成図。
【図３】拡張なしの場合の具体的ユニット構成図。
【図４】拡張あり場合の具体的ユニット構成図。
【図５】コアユニット自体の拡張構成図。
【図６】４，６気筒エンジンに用いる場合の標準ユニット構成図。
【図７】故障診断を加えた６気筒エンジンあるいは自動変速機制御を加えた６気筒エンジンの場合の標準ユニット構成図。
【図８】６気筒統合制御の場合の標準ユニット構成図。
【図９】コアユニットを用いた場合のエンジン・ＡＴ制御ユニット構成図。
【図１０】コアユニットを用いた場合のＡＢＳ・トラクション制御ユニット構成図。
【図１１】ＬＡＮ（Local Area Network）を用いた場合のシステム構成図。
【図１２】演算ユニットとＩ／ＯユニットをＬＡＮで通信した場合の構成図。
【図１３】従来の空気流量（ＨＷ式）センサ信号の処理構成図。
【図１４】従来の空気流量（吸気管内圧力式）センサ信号の処理構成図。
【図１５】インターフェースソフト内蔵内部ＲＯＭ搭載した標準ユニットの入力信号処理構成図。
【図１６】可変式ハードフィルタを用いた入力信号処理構成図。
【図１７】使用センサ分にハードフィルタを備えた入力信号処理構成図。
【図１８】インターフェースソフトによるポート割当機能の概略図。
【図１９】インターフェースソフトによる入力信号の組み合わせ処理の構成図。
【図２０】インターフェースソフトによるセンサ入力時の演算処理機能を示す図。
【図２１】インターフェースソフトによる時間割付の概略図。
【図２２】時間割付の詳細制御フローチャート。
【図２３】インターフェースソフトによる割り込みレベル割付プログラムのフローチャート。
【図２４】最適入出力ポート割当のパターン決定のフローチャート。
【図２５】ＲＡＭ領域内における多用データ一括集団配置図。
【図２６】多用データ一括配置のフローチャート。
【図２７】監視プログラムを利用した異常箇所発見の簡単なフローチャート。
【図２８】基本処理プログラムの組み込み関数化の構成図。
【図２９】一般的自動車制御用変数の定義及び宣言の関数化の図。
【図３０】組み込み関数の仕様を示す図。
【図３１】基本処理関数の処理選択機能の手段を示す図。
【符号の説明】
１…コアユニット、２…内部ＲＯＭ、３…ＣＰＵ（中央演算処理装置）、４…ＲＡＭ（書き換え可能なメモリ）、５…拡張手段、６…拡張Ｉ／Ｏ、７…外付けＲＯＭ
Claims (5)
- スロットル開度を検出するセンサからの情報、空気流量を検出するセンサからの情報、水温を検出するセンサからの情報のうちの何れか１つ以上のアナログ情報が入力される入力部と、
前記入力部から入力されたアナログ情報の処理を行うハードフィルタと、
自動変速機の油圧を制御するアクチュエータ、変速位置を制御するソレノイドのうちの何れか１つ以上のアクチュエータを制御する信号を出力する出力部と、
前記アクチュエータを制御して自動変速機を制御するためのプログラムが格納されたメモリと、
前記プログラムを演算実行する中央演算処理部と、を備え、
前記プログラムは、インターフェースソフト及びアプリケーションソフトを有し、
前記アプリケーションソフトは、前記アクチュエータを制御する演算を行うための機能を有し、
前記インターフェースソフトは、前記アプリケーションソフトとＯＳ（オペレーティングシステム）の仲介を行うための機能を有し、
前記インターフェースソフトから前記アプリケーションソフトへの信号の授受は、関数を用いて行なわれ、
前記メモリ及び中央演算処理部は、シングルチップマイコンとして構成される自動変速機制御ユニット。 - 請求項１記載の自動変速機制御ユニットにおいて、
前記関数は仕様書において標準化された関数であることを特徴とする自動変速機制御ユニット。 - 自動変速機を制御する為に、スロットル開度、空気流量、水温、アイドルスイッチ、車速を検出するセンサのうちの何れか１つ以上のアナログ情報の処理を行うハードフィルタと、
前記ハードフィルタを通った前記アナログ情報のうちから何れか１つ以上を選択するマルチプレクサと、
前記マルチプレクサの出力をディジタル信号に変換するＡ／Ｄコンバータと、
前記Ａ／Ｄコンバータからのディジタル信号に基づいて、自動変速機の油圧を制御するアクチュエータ、変速位置を制御するソレノイドのうちの何れか１つ以上のアクチュエータに送る情報を演算するアプリケーションソフトと、
前記アプリケーションソフトとの間で相互に信号の授受を行うインターフェースソフトであって、スロットル開度、空気流量、水温、アイドルスイッチ、車速のうちの何れか１つ以上の情報に基づいて前記アプリケーションソフトへ送る信号を演算するインターフェースソフトと、
が書き込まれたメモリと、
前記アプリケーションソフトと前記インターフェースソフトとを演算実行する１つの中央演算処理装置とを有し、
前記アプリケーションソフト及び／又は前記インターフェースソフトは互いに独立に修正可能であり、前記インターフェースソフトから前記アプリケーションソフトへの信号の授受が仕様書において標準化された関数を用いて行われる構成で作成された自動変速機制御ユニット。 - 請求項１から３のいずれか１項記載の自動変速機制御ユニットにおいて、
前記アプリケーションソフトが、変速点制御又はロックアップ制御を行うものであることを特徴とする自動変速機制御ユニット。 - 請求項１から４のいずれか１項記載の自動変速機制御ユニットにおいて、
前記アプリケーションソフト及び／又は前記インターフェースソフトはＣ言語を用いて記述されたことを特徴とする自動変速機制御ユニット。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000369161A JP3803245B2 (ja) | 2000-12-04 | 2000-12-04 | 自動変速機制御ユニット |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000369161A JP3803245B2 (ja) | 2000-12-04 | 2000-12-04 | 自動変速機制御ユニット |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP5184101A Division JPH0740794A (ja) | 1993-07-26 | 1993-07-26 | 自動車用制御ユニット |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001000237A Division JP2001277961A (ja) | 2001-01-04 | 2001-01-04 | 自動車用制御ユニット |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001216004A JP2001216004A (ja) | 2001-08-10 |
| JP3803245B2 true JP3803245B2 (ja) | 2006-08-02 |
Family
ID=18839245
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000369161A Expired - Fee Related JP3803245B2 (ja) | 2000-12-04 | 2000-12-04 | 自動変速機制御ユニット |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3803245B2 (ja) |
-
2000
- 2000-12-04 JP JP2000369161A patent/JP3803245B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001216004A (ja) | 2001-08-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5638272A (en) | Control unit for vehicle and total control system therefor | |
| US6009370A (en) | Control unit for vehicle and total control system therefor | |
| JP2574892B2 (ja) | 自動車における負荷分担制御方法 | |
| JP4728020B2 (ja) | 車両制御用ソフトウェア及び車両制御装置 | |
| US6415394B1 (en) | Method and circuit for analysis of the operation of a microcontroller using signature analysis during operation | |
| JPH1195803A (ja) | システムに対する制御装置および制御装置の駆動方法 | |
| JPH04169350A (ja) | イベント駆動型車両制御用コンピュータ | |
| US5544054A (en) | Vehicle multi-processor control system and method with processing load optimization | |
| JP3688224B2 (ja) | 自動車用制御ユニット | |
| US20120246650A1 (en) | Method for processing information and activities in a control and/or regulating system with the aid of a multi-core processor | |
| US6334080B1 (en) | Vehicle control apparatus and method sharing control data | |
| JP3726295B2 (ja) | 車両用制御装置 | |
| KR19990087086A (ko) | 계산 유닛의 기능 체크 방법 | |
| JPH0740794A (ja) | 自動車用制御ユニット | |
| US8392046B2 (en) | Monitoring the functional reliability of an internal combustion engine | |
| JP6306530B2 (ja) | 自動車用電子制御装置 | |
| JP3803245B2 (ja) | 自動変速機制御ユニット | |
| JP2001290510A (ja) | 自動車用制御ユニット | |
| JP2010122752A (ja) | 制御装置 | |
| JP4422076B2 (ja) | データ処理装置、電子制御ユニット、ならびに自動車 | |
| JP2001277961A (ja) | 自動車用制御ユニット | |
| JP7139633B2 (ja) | 並列化方法、並列化ツール、及びマルチコアマイコン | |
| JP2022045239A (ja) | 電子制御装置 | |
| JP2565141B2 (ja) | 自動車における負荷分担制御方法 | |
| JP5690492B2 (ja) | 車載制御装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050405 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050606 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060124 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060327 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060411 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060502 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100512 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |