JPH07107564A - 車両用通信システムの異常検出装置 - Google Patents
車両用通信システムの異常検出装置Info
- Publication number
- JPH07107564A JPH07107564A JP5249473A JP24947393A JPH07107564A JP H07107564 A JPH07107564 A JP H07107564A JP 5249473 A JP5249473 A JP 5249473A JP 24947393 A JP24947393 A JP 24947393A JP H07107564 A JPH07107564 A JP H07107564A
- Authority
- JP
- Japan
- Prior art keywords
- data
- communication
- abnormality
- cpu
- code
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
- G06F11/221—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test buses, lines or interfaces, e.g. stuck-at or open line faults
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/005—Testing of electric installations on transport means
- G01R31/006—Testing of electric installations on transport means on road vehicles, e.g. automobiles or trucks
- G01R31/007—Testing of electric installations on transport means on road vehicles, e.g. automobiles or trucks using microprocessors or computers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Chemical & Material Sciences (AREA)
- Combustion & Propulsion (AREA)
- Selective Calling Equipment (AREA)
- Small-Scale Networks (AREA)
- Testing And Monitoring For Control Systems (AREA)
Abstract
(57)【要約】
【目的】 制御装置と診断装置とからなる車両用通信シ
ステムにおいて、通信異常を検出できる車両用通信シス
テムの異常検出装置を提供する。 【構成】 制御装置１００、２００は、通信ＩＣ１４０
により診断装置３００へ送信するデータを蓄積し、第１
のタイミングでバス４００に送信すると、ＣＰＵ１１０
により第２のタイミングにおける通信ＩＣ１４０に蓄積
されているデータの状態に応じて通信ＩＣ１４０周辺の
通信異常を検出する。またＣＰＵ１１０は、通信ＩＣ１
４０からデータがバス４００に送信後、通信ＩＣ１４０
にそのデータが蓄積されている場合、異常と判断する。
またＣＰＵ１１０は、データの１部を通信ＩＣ１４０に
送信後、通信ＩＣ１４０にデータが蓄積されていない場
合、異常と判断する。
ステムにおいて、通信異常を検出できる車両用通信シス
テムの異常検出装置を提供する。 【構成】 制御装置１００、２００は、通信ＩＣ１４０
により診断装置３００へ送信するデータを蓄積し、第１
のタイミングでバス４００に送信すると、ＣＰＵ１１０
により第２のタイミングにおける通信ＩＣ１４０に蓄積
されているデータの状態に応じて通信ＩＣ１４０周辺の
通信異常を検出する。またＣＰＵ１１０は、通信ＩＣ１
４０からデータがバス４００に送信後、通信ＩＣ１４０
にそのデータが蓄積されている場合、異常と判断する。
またＣＰＵ１１０は、データの１部を通信ＩＣ１４０に
送信後、通信ＩＣ１４０にデータが蓄積されていない場
合、異常と判断する。
Description
【０００１】
【産業上の利用分野】本発明は、制御装置間でデータの
通信を行う車両用通信システム、特に車両の制御を行う
制御装置と、この制御装置にて処理されるデータの読出
しを行う診断装置とからなる車両用通信システムの通信
異常を検出する異常検出装置に関する。
通信を行う車両用通信システム、特に車両の制御を行う
制御装置と、この制御装置にて処理されるデータの読出
しを行う診断装置とからなる車両用通信システムの通信
異常を検出する異常検出装置に関する。
【０００２】
【従来の技術】従来、車両の種々の制御を分担して行う
複数の制御装置において、制御装置間で共通データ等を
バスを介して通信を行う車両用通信システムがある。こ
のような車両用通信システムの通信異常を検出する装置
として、制御装置から送信されたデータに対して受信し
た制御装置がアンサーバックする構成とし、データ送信
後所定期間内にアンサーバックされるか否かにより通信
異常を検出する異常検出装置が知られている。また車両
の制御状態の覆歴を読みだすために、制御装置に対しバ
スを介して通信を行う診断装置を接続することも知られ
ている。
複数の制御装置において、制御装置間で共通データ等を
バスを介して通信を行う車両用通信システムがある。こ
のような車両用通信システムの通信異常を検出する装置
として、制御装置から送信されたデータに対して受信し
た制御装置がアンサーバックする構成とし、データ送信
後所定期間内にアンサーバックされるか否かにより通信
異常を検出する異常検出装置が知られている。また車両
の制御状態の覆歴を読みだすために、制御装置に対しバ
スを介して通信を行う診断装置を接続することも知られ
ている。
【０００３】
【発明が解決しようとする課題】前述のような制御装置
を有する車両用通信システムにおいては診断装置はディ
ーラー等により制御装置に記憶されている車両の異常検
出データを読出す時に制御装置に接続するものである。
したがって、制御装置は診断装置が接続されているか否
かは判断できないため、前述のようなアンサーバックの
方法による異常検出はできないという問題点がある。
を有する車両用通信システムにおいては診断装置はディ
ーラー等により制御装置に記憶されている車両の異常検
出データを読出す時に制御装置に接続するものである。
したがって、制御装置は診断装置が接続されているか否
かは判断できないため、前述のようなアンサーバックの
方法による異常検出はできないという問題点がある。
【０００４】本発明は、上記問題点に鑑み、制御装置を
有する車両用通信システムにおける通信異常を検出でき
る車両用通信システムの異常検出装置を提供することを
目的とする。
有する車両用通信システムにおける通信異常を検出でき
る車両用通信システムの異常検出装置を提供することを
目的とする。
【０００５】
【課題を解決するための手段】本発明は、前記問題点を
解決するために、車両の制御を行う制御装置が、車両の
制御状態を診断するためにこの制御装置にて処理される
データの読出しをバスを介して行う診断装置を外部に接
続可能となっている車両用通信システムにおいて、前記
制御装置は、前記診断装置へ送信する前記データを蓄積
し、第１のタイミングで前記バスに送信するバッファ手
段と、第２のタイミングにおける前記バッファ手段に蓄
積されている前記データの状態に応じて前記バッファ手
段周辺の通信異常を検出する通信異常検出手段とを備え
ることを特徴とする車両用通信システムの異常検出装置
を提供する。
解決するために、車両の制御を行う制御装置が、車両の
制御状態を診断するためにこの制御装置にて処理される
データの読出しをバスを介して行う診断装置を外部に接
続可能となっている車両用通信システムにおいて、前記
制御装置は、前記診断装置へ送信する前記データを蓄積
し、第１のタイミングで前記バスに送信するバッファ手
段と、第２のタイミングにおける前記バッファ手段に蓄
積されている前記データの状態に応じて前記バッファ手
段周辺の通信異常を検出する通信異常検出手段とを備え
ることを特徴とする車両用通信システムの異常検出装置
を提供する。
【０００６】また前記通信異常検出手段は、前記バッフ
ァ手段から前記データを前記バスに送信後、前記バッフ
ァ手段に前記データが蓄積されている場合、第１異常と
判断する第１異常判断手段を備えてもよい。また前記通
信異常検出手段は、前記データの１部を前記バッファ手
段に送信後、前記バッファ手段に前記データが蓄積され
ていない場合、第２異常と判断する第２異常判断手段を
備えてもよい。
ァ手段から前記データを前記バスに送信後、前記バッフ
ァ手段に前記データが蓄積されている場合、第１異常と
判断する第１異常判断手段を備えてもよい。また前記通
信異常検出手段は、前記データの１部を前記バッファ手
段に送信後、前記バッファ手段に前記データが蓄積され
ていない場合、第２異常と判断する第２異常判断手段を
備えてもよい。
【０００７】
【作用】前記構成よりなる本発明によれば、車両の制御
を行う制御装置が、車両の制御状態を診断するためにこ
の制御装置にて処理されるデータの読出しをバスを介し
て行う診断装置を外部に接続可能となっている車両用通
信システムにおいて、この制御装置は、バッファ手段に
より診断装置へ送信するデータを蓄積し、第１のタイミ
ングでバスに送信すると、通信異常検出手段により第２
のタイミングにおけるバッファ手段に蓄積されているデ
ータの状態に応じてバッファ手段周辺の通信異常を検出
する。
を行う制御装置が、車両の制御状態を診断するためにこ
の制御装置にて処理されるデータの読出しをバスを介し
て行う診断装置を外部に接続可能となっている車両用通
信システムにおいて、この制御装置は、バッファ手段に
より診断装置へ送信するデータを蓄積し、第１のタイミ
ングでバスに送信すると、通信異常検出手段により第２
のタイミングにおけるバッファ手段に蓄積されているデ
ータの状態に応じてバッファ手段周辺の通信異常を検出
する。
【０００８】
【実施例】以下、本発明を適用した実施例を説明する。
図１中（ａ）は制御装置１００、２００、診断装置３０
０等から構成される車両用通信システムの構成図であ
る。制御装置１００、２００と診断装置３００とはそれ
ぞれバス４００にて接続され、種々のデータ通信を行う
構成となっている。
図１中（ａ）は制御装置１００、２００、診断装置３０
０等から構成される車両用通信システムの構成図であ
る。制御装置１００、２００と診断装置３００とはそれ
ぞれバス４００にて接続され、種々のデータ通信を行う
構成となっている。
【０００９】制御装置１００、２００は車両の種々の制
御、例えばエンジン制御・トランスミッション制御・ト
ラクション制御・ブレーキ制御等を複数の制御装置で分
担して行っている。また、各制御装置１００、２００は
それぞれ異常検出処理を行っている。各制御装置間では
バス４００を介してセンサ信号データ、制御データ等の
各種データの通信を行っている。
御、例えばエンジン制御・トランスミッション制御・ト
ラクション制御・ブレーキ制御等を複数の制御装置で分
担して行っている。また、各制御装置１００、２００は
それぞれ異常検出処理を行っている。各制御装置間では
バス４００を介してセンサ信号データ、制御データ等の
各種データの通信を行っている。
【００１０】診断装置３００はバス４００を介して制御
装置１００、２００と接続可能であり、制御装置１０
０、２００で処理された異常検出データ等が読出し可能
となっている。制御装置１００の詳細構成について以下
に説明する。なお、制御装置２００に関しては制御装置
１００と同様の構成のため説明を省略する。制御装置１
００は各種制御を行う３つのＣＰＵ１１０、１２０、１
３０を有する。バス４００を介して他の制御装置２００
や診断装置３００との間で各種データの送・受信を行う
ために、通信ＩＣ１４０、ドライバ／レシーバ１４５を
有する。車載バッテリ１６０からイグニッションスイッ
チＩＧＳＷ１７０を介して供給される電圧＋Ｂ（＝１２
Ｖ）を電圧Ｖｃｃ（＝５Ｖ）に変換して各ＣＰＵ１１
０，１２０，１３０および通信ＩＣ１４０に供給する電
源ＩＣ１５０を有する。さらに、車両の各種状態を検出
するセンサからの信号が入力されると共に、センサ信号
に基づいて車両を制御する各種のアクチュエータに制御
信号を出力する。
装置１００、２００と接続可能であり、制御装置１０
０、２００で処理された異常検出データ等が読出し可能
となっている。制御装置１００の詳細構成について以下
に説明する。なお、制御装置２００に関しては制御装置
１００と同様の構成のため説明を省略する。制御装置１
００は各種制御を行う３つのＣＰＵ１１０、１２０、１
３０を有する。バス４００を介して他の制御装置２００
や診断装置３００との間で各種データの送・受信を行う
ために、通信ＩＣ１４０、ドライバ／レシーバ１４５を
有する。車載バッテリ１６０からイグニッションスイッ
チＩＧＳＷ１７０を介して供給される電圧＋Ｂ（＝１２
Ｖ）を電圧Ｖｃｃ（＝５Ｖ）に変換して各ＣＰＵ１１
０，１２０，１３０および通信ＩＣ１４０に供給する電
源ＩＣ１５０を有する。さらに、車両の各種状態を検出
するセンサからの信号が入力されると共に、センサ信号
に基づいて車両を制御する各種のアクチュエータに制御
信号を出力する。
【００１１】図１中（ｂ）は図１中（ａ）におけるＣＰ
Ｕ１１０、通信ＩＣ１４０、ドライバ／レシーバ１４５
およびバス４００についての詳細構成図である。ＣＰＵ
１１０から通信ＩＣ１４０にデータを送信するためのＣ
ＰＵ１１０の端子ＡＳＴＸ，ＴＸは通信ＩＣ１４０の端
子ＡＳＴＸ，ＲＸＨに接続されており、ＡＳＴＸがＬレ
ベルの時にＴＸから出力されるデータを１メッセージと
する。端子ＡＢＳＹは通信ＩＣ１４０の中のバッファの
状態を示すものであり、バッファにデータがある時はＬ
レベルを示す。通信ＩＣ１４０からＣＰＵ１１０にデー
タを送信するための通信ＩＣ１４０の端子ＡＲＴＳ，Ｔ
ＸＨはＣＰＵ１１０の端子ＡＲＴＳ，ＲＸに接続されて
おり、ＡＲＴＳがＬレベルの時にＴＸＨから出力される
データを１メッセージとする。通信ＩＣ１４０からドラ
イバ／レシーバ１４５にデータを送信するための通信Ｉ
Ｃ１４０の端子ＴＸＪが、ドライバ／レシーバ１４５の
端子ＩＮに接続され、ドライバ／レシーバ１４５から通
信ＩＣ１４０にデータを送信するためのドライバ／レシ
ーバ１４５の端子ＯＵＴが、通信ＩＣの端子ＲＸＪに接
続されている。ドライバ／レシーバ１４５はバス４００
へ２つの端子ＤＲを介してデータの送・受信を行う。
Ｕ１１０、通信ＩＣ１４０、ドライバ／レシーバ１４５
およびバス４００についての詳細構成図である。ＣＰＵ
１１０から通信ＩＣ１４０にデータを送信するためのＣ
ＰＵ１１０の端子ＡＳＴＸ，ＴＸは通信ＩＣ１４０の端
子ＡＳＴＸ，ＲＸＨに接続されており、ＡＳＴＸがＬレ
ベルの時にＴＸから出力されるデータを１メッセージと
する。端子ＡＢＳＹは通信ＩＣ１４０の中のバッファの
状態を示すものであり、バッファにデータがある時はＬ
レベルを示す。通信ＩＣ１４０からＣＰＵ１１０にデー
タを送信するための通信ＩＣ１４０の端子ＡＲＴＳ，Ｔ
ＸＨはＣＰＵ１１０の端子ＡＲＴＳ，ＲＸに接続されて
おり、ＡＲＴＳがＬレベルの時にＴＸＨから出力される
データを１メッセージとする。通信ＩＣ１４０からドラ
イバ／レシーバ１４５にデータを送信するための通信Ｉ
Ｃ１４０の端子ＴＸＪが、ドライバ／レシーバ１４５の
端子ＩＮに接続され、ドライバ／レシーバ１４５から通
信ＩＣ１４０にデータを送信するためのドライバ／レシ
ーバ１４５の端子ＯＵＴが、通信ＩＣの端子ＲＸＪに接
続されている。ドライバ／レシーバ１４５はバス４００
へ２つの端子ＤＲを介してデータの送・受信を行う。
【００１２】図２に各ＣＰＵ１１０、１２０、１３０の
ＲＡＭの構成図を示す。なお、各ＣＰＵ１１０、１２
０、１３０はＲＯＭ、ＲＡＭを内蔵する１チップマイコ
ンにより構成される。領域は通常のＲＡＭ領域であ
り、各種の演算データ等が記憶される。ＲＡＭ領域の
中の領域はダイレクト・メモリ・アクセス領域（以下
ＤＭＡ領域と略す）である。このＤＭＡ領域中の領域
’、”はそれぞれ、ＤＭＡ送信領域、ＤＭＡ受信領
域である。そして、このＤＭＡ送信領域’に記憶され
ているデータは所定期間（例えば、４ｍｓｅｃ）毎に他
のＣＰＵのＤＭＡ受信領域”へ送信される。そして、
このＤＭＡ受信領域”に受信されたデータは、同じＤ
ＭＡ領域内のＤＭＡ送信領域’へ送られる。このよ
うにして図１中（ａ）に示すように各ＣＰＵ１１０、１
２０、１３０はＤＭＡによりそれぞれのデータを他のＣ
ＰＵにリング形式（例えば、ＣＰＵ１１０→ＣＰＵ１２
０→ＣＰＵ１３０→ＣＰＵ１１０の順番）によりデータ
送信している。また領域はイグニッションスイッチ
ＩＧＳＷ１７０がオフとなってもその記憶内容が保持さ
れるスタンバイＲＡＭ領域（以下、ＳＲＡＭ領域と略
す）であり、車両の異常情報等が記憶される。
ＲＡＭの構成図を示す。なお、各ＣＰＵ１１０、１２
０、１３０はＲＯＭ、ＲＡＭを内蔵する１チップマイコ
ンにより構成される。領域は通常のＲＡＭ領域であ
り、各種の演算データ等が記憶される。ＲＡＭ領域の
中の領域はダイレクト・メモリ・アクセス領域（以下
ＤＭＡ領域と略す）である。このＤＭＡ領域中の領域
’、”はそれぞれ、ＤＭＡ送信領域、ＤＭＡ受信領
域である。そして、このＤＭＡ送信領域’に記憶され
ているデータは所定期間（例えば、４ｍｓｅｃ）毎に他
のＣＰＵのＤＭＡ受信領域”へ送信される。そして、
このＤＭＡ受信領域”に受信されたデータは、同じＤ
ＭＡ領域内のＤＭＡ送信領域’へ送られる。このよ
うにして図１中（ａ）に示すように各ＣＰＵ１１０、１
２０、１３０はＤＭＡによりそれぞれのデータを他のＣ
ＰＵにリング形式（例えば、ＣＰＵ１１０→ＣＰＵ１２
０→ＣＰＵ１３０→ＣＰＵ１１０の順番）によりデータ
送信している。また領域はイグニッションスイッチ
ＩＧＳＷ１７０がオフとなってもその記憶内容が保持さ
れるスタンバイＲＡＭ領域（以下、ＳＲＡＭ領域と略
す）であり、車両の異常情報等が記憶される。
【００１３】以下、制御装置１００、２００と診断装置
３００との間で行われるデータ通信について説明する。
図３は診断者が診断装置３００により制御装置１００、
２００に記憶されている種々の情報を読み出す場合の診
断装置３００での処理を示すフローチャートであり所定
周期毎に起動される（以下制御装置１００に記憶されて
いる情報を読み出す場合について説明する）。また図４
は図３のステップ５２０とステップ５２０とステップ５
４０とにおける送信データの例を表した図である。
３００との間で行われるデータ通信について説明する。
図３は診断者が診断装置３００により制御装置１００、
２００に記憶されている種々の情報を読み出す場合の診
断装置３００での処理を示すフローチャートであり所定
周期毎に起動される（以下制御装置１００に記憶されて
いる情報を読み出す場合について説明する）。また図４
は図３のステップ５２０とステップ５２０とステップ５
４０とにおける送信データの例を表した図である。
【００１４】まずステップ５００で診断者からの処理要
求の有無を検出する。処理要求が無い場合は本処理を終
了する。処理要求が有る場合はステップ５１０で処理要
求の種類を検出する。処理要求としては制御装置１００
にて検出した異常検出情報であるダイアグコードを読み
出す「コ−ド読出要求」、制御装置１００に記憶されて
いるダイアグコードを消去する「コード消去要求」、各
ＣＰＵ１１０、１２０、１３０のＲＡＭの所望アドレス
のデータ（ＲＡＭ値）を読み出す「ＲＡＭ値読出要求」
等である。
求の有無を検出する。処理要求が無い場合は本処理を終
了する。処理要求が有る場合はステップ５１０で処理要
求の種類を検出する。処理要求としては制御装置１００
にて検出した異常検出情報であるダイアグコードを読み
出す「コ−ド読出要求」、制御装置１００に記憶されて
いるダイアグコードを消去する「コード消去要求」、各
ＣＰＵ１１０、１２０、１３０のＲＡＭの所望アドレス
のデータ（ＲＡＭ値）を読み出す「ＲＡＭ値読出要求」
等である。
【００１５】ステップ５１０で検出した処理要求が「コ
−ド読出要求」である場合はステップ５２０でコード読
出要求を制御装置１００へ出力する。送信データとして
は図４中（１）に示すような構成である。ここで、図４
の（ａ）の部分は制御装置１００にて診断装置３００か
らの送信データが自分自身に対するものかを判断するた
めの情報であるヘッダであり、また図４の（ｂ）の部分
はコード読出要求を示すデータである。
−ド読出要求」である場合はステップ５２０でコード読
出要求を制御装置１００へ出力する。送信データとして
は図４中（１）に示すような構成である。ここで、図４
の（ａ）の部分は制御装置１００にて診断装置３００か
らの送信データが自分自身に対するものかを判断するた
めの情報であるヘッダであり、また図４の（ｂ）の部分
はコード読出要求を示すデータである。
【００１６】ステップ５１０で検出した診断者からの処
理要求が「コ−ド消去要求」である場合はステップ５３
０でコード消去要求を制御装置１００へ出力する。送信
データとしては図４中（２）に示すような構成である。
ここで、図４の（ｃ）の部分はコード消去要求を示すデ
ータである。ステップ５１０で検出した処理要求が「Ｒ
ＡＭ値読出要求」である場合はステップ５４０でＲＡＭ
値読出要求を制御装置１００へ出力する。詳細には、制
御装置１００内のＣＰＵ１１０，１２０，１３０の、ど
のＣＰＵの、どのアドレスのＲＡＭ値を読み出すかとい
う情報を送信する。送信データとしては図４中（３）に
示すような構成である。ここで、（ｄ）の部分はＲＡＭ
値読出要求を示すデータ、（ｅ）の部分は対象ＣＰＵの
番号を示すデータ、（ｆ）の部分は要求アドレス値を示
すデータである。図４に示すように送・受信データは１
メッセージがデータの種類によってバイト数が異なって
いる。
理要求が「コ−ド消去要求」である場合はステップ５３
０でコード消去要求を制御装置１００へ出力する。送信
データとしては図４中（２）に示すような構成である。
ここで、図４の（ｃ）の部分はコード消去要求を示すデ
ータである。ステップ５１０で検出した処理要求が「Ｒ
ＡＭ値読出要求」である場合はステップ５４０でＲＡＭ
値読出要求を制御装置１００へ出力する。詳細には、制
御装置１００内のＣＰＵ１１０，１２０，１３０の、ど
のＣＰＵの、どのアドレスのＲＡＭ値を読み出すかとい
う情報を送信する。送信データとしては図４中（３）に
示すような構成である。ここで、（ｄ）の部分はＲＡＭ
値読出要求を示すデータ、（ｅ）の部分は対象ＣＰＵの
番号を示すデータ、（ｆ）の部分は要求アドレス値を示
すデータである。図４に示すように送・受信データは１
メッセージがデータの種類によってバイト数が異なって
いる。
【００１７】制御装置１００での異常検出処理および異
常情報記憶処理を説明する。図５は、例えば後述する図
６に示すような、異常検出処理にて異常が検出された場
合、その異常に応じたダイアグコードを上記ＳＲＡＭ領
域へ記憶させる処理を示すフローチャートであり、
所定周期毎に起動される。なお、この処理は各ＣＰＵ１
１０、１２０、１３０において実行される。
常情報記憶処理を説明する。図５は、例えば後述する図
６に示すような、異常検出処理にて異常が検出された場
合、その異常に応じたダイアグコードを上記ＳＲＡＭ領
域へ記憶させる処理を示すフローチャートであり、
所定周期毎に起動される。なお、この処理は各ＣＰＵ１
１０、１２０、１３０において実行される。
【００１８】まずステップ６００でＣＰＵ１１０、１２
０、１３０に供給される電圧Ｖｃｃが所定電圧以下また
は車載バッテリ１６０の電圧＋Ｂが所定電圧以下である
低電圧状態で有るか否かを判定する。低電圧状態と判定
された場合はセンサかアクチュエータか制御装置１００
の誤動作（ＳＲＡＭ領域のデータ更新の誤動作等）
が考えられるためＳＲＡＭ領域へのダイアグコード
の記憶を中止して本処理を終了する。ステップ６００に
て低電圧状態でないと判定した場合はステップ６１０
で、例えば図６に示される異常検出処理にて異常が検出
されているか否かを判定する。これは図６にて、水温セ
ンサが異常であることを示す通常のＲＡＭ領域に設
定されたフラグＸＤ００の状態を検出している。異常が
検出されていない場合は本処理を終了する。異常が検出
されている場合はステップ６２０にて通常のＲＡＭ領域
に記憶されているダイアグコードをＳＲＡＭ領域
にコピーして本処理を終了する。例えば、水温センサ
が異常であることを示す、ＳＲＡＭ領域に設定され
たフラグＸＤ００をセットする。
０、１３０に供給される電圧Ｖｃｃが所定電圧以下また
は車載バッテリ１６０の電圧＋Ｂが所定電圧以下である
低電圧状態で有るか否かを判定する。低電圧状態と判定
された場合はセンサかアクチュエータか制御装置１００
の誤動作（ＳＲＡＭ領域のデータ更新の誤動作等）
が考えられるためＳＲＡＭ領域へのダイアグコード
の記憶を中止して本処理を終了する。ステップ６００に
て低電圧状態でないと判定した場合はステップ６１０
で、例えば図６に示される異常検出処理にて異常が検出
されているか否かを判定する。これは図６にて、水温セ
ンサが異常であることを示す通常のＲＡＭ領域に設
定されたフラグＸＤ００の状態を検出している。異常が
検出されていない場合は本処理を終了する。異常が検出
されている場合はステップ６２０にて通常のＲＡＭ領域
に記憶されているダイアグコードをＳＲＡＭ領域
にコピーして本処理を終了する。例えば、水温センサ
が異常であることを示す、ＳＲＡＭ領域に設定され
たフラグＸＤ００をセットする。
【００１９】図６は異常検出処理の代表例として水温セ
ンサの異常検出処理を示すフローチャートであり、水温
センサ出力値がＡ／Ｄ変換される毎に起動される。な
お、種々の異常検出処理がＣＰＵ１１０、１２０、１３
０で分担して実行される。まずステップ７００で水温セ
ンサ信号のＡ／Ｄ値を読み込む。ステップ７１０で読み
込んだＡ／Ｄ値が異常か否かを判定する。判定方法とし
てはＡ／Ｄ値が所定範囲内で無い場合には異常と判断す
る等である。正常と判定された場合はステップ７２０で
正常時における処理（例えば、所定のＲＡＭ領域にＡ／
Ｄ値を書き込む）を実行し本処理を終了する。異常と判
定された場合はステップ７３０でフェイルセーフ処理
（例えば、所定のＲＡＭ領域に所定値を書き込む）を実
行した後、ステップ７４０でフラグＸＤ００をセットし
本処理を終了する。
ンサの異常検出処理を示すフローチャートであり、水温
センサ出力値がＡ／Ｄ変換される毎に起動される。な
お、種々の異常検出処理がＣＰＵ１１０、１２０、１３
０で分担して実行される。まずステップ７００で水温セ
ンサ信号のＡ／Ｄ値を読み込む。ステップ７１０で読み
込んだＡ／Ｄ値が異常か否かを判定する。判定方法とし
てはＡ／Ｄ値が所定範囲内で無い場合には異常と判断す
る等である。正常と判定された場合はステップ７２０で
正常時における処理（例えば、所定のＲＡＭ領域にＡ／
Ｄ値を書き込む）を実行し本処理を終了する。異常と判
定された場合はステップ７３０でフェイルセーフ処理
（例えば、所定のＲＡＭ領域に所定値を書き込む）を実
行した後、ステップ７４０でフラグＸＤ００をセットし
本処理を終了する。
【００２０】制御装置１００にて診断装置３００との間
で行われるデータ通信処理について説明する。図７はＩ
ＧＳＷ１７０がオンされた時のみ制御装置１００にて実
行されるイニシャルルーティンを示すフローチャートで
ある。ステップ８００でｎＤＡＴＡに予め設定された通
常の通信処理では使用しない値、例えば＄ＦＦをセット
して本処理を終了する。
で行われるデータ通信処理について説明する。図７はＩ
ＧＳＷ１７０がオンされた時のみ制御装置１００にて実
行されるイニシャルルーティンを示すフローチャートで
ある。ステップ８００でｎＤＡＴＡに予め設定された通
常の通信処理では使用しない値、例えば＄ＦＦをセット
して本処理を終了する。
【００２１】ここで、ｎＤＡＴＡは診断装置３００との
間でデータ通信を行うＣＰＵ１１０中の送受信バッファ
ＲＢＵＦ〔１１〕のメッセージ長を示す。このＲＢＵＦ
〔１１〕，ｎＤＡＴＡについて図８を用いて説明する。
ＲＢＵＦ〔１１〕は図８中（ａ）に示すように１１バイ
トのバッファであり、このＲＢＵＦ〔１１〕の各バイト
にデータがＲＢＵＦ〔１〕，ＲＢＵＦ〔２〕・・・の順
に書き込まれる。この書き込まれたＲＢＵＦ〔１１〕の
バイト数、即ちＲＢＵＦ〔１１〕のメッセージ長がｎＤ
ＡＴＡである。例えば、図８中（ｂ）の場合はｎＤＡＴ
Ａ＝５である。
間でデータ通信を行うＣＰＵ１１０中の送受信バッファ
ＲＢＵＦ〔１１〕のメッセージ長を示す。このＲＢＵＦ
〔１１〕，ｎＤＡＴＡについて図８を用いて説明する。
ＲＢＵＦ〔１１〕は図８中（ａ）に示すように１１バイ
トのバッファであり、このＲＢＵＦ〔１１〕の各バイト
にデータがＲＢＵＦ〔１〕，ＲＢＵＦ〔２〕・・・の順
に書き込まれる。この書き込まれたＲＢＵＦ〔１１〕の
バイト数、即ちＲＢＵＦ〔１１〕のメッセージ長がｎＤ
ＡＴＡである。例えば、図８中（ｂ）の場合はｎＤＡＴ
Ａ＝５である。
【００２２】図９は制御装置１００での診断装置３００
とのデータ送受信処理を示すフローチャートである。ス
テップ８１０〜８２５はバス４００が所定時間（例えば
１．０ｓｅｃ）以上アイドル状態にならない時、バス異
常と判断するロジックである。ステップ８１０でＡＢＳ
ＹがＨか否かを検出する。ステップ８１０でＡＢＳＹが
Ｌの場合はステップ８１５でＴＩＭＥＲが１．０ｓｅｃ
以上か否かを検出する。ここでＴＩＭＥＲはＡＢＳＹが
Ｌの時間を計測するタイマーである。ＴＩＭＥＲが１．
０ｓｅｃ未満の時は本処理を終了する。ＴＩＭＥＲが
１．０ｓｅｃ以上、ＡＢＳＹが連続で１．０ｓｅｃ以上
Ｌである時、即ちバス４００が所定時間以上アイドル状
態にならない時、バス異常を起こしたと判断してステッ
プ８２０で通信異常を示すフラグＸＦＡＩＬをセットし
本処理を終了する。
とのデータ送受信処理を示すフローチャートである。ス
テップ８１０〜８２５はバス４００が所定時間（例えば
１．０ｓｅｃ）以上アイドル状態にならない時、バス異
常と判断するロジックである。ステップ８１０でＡＢＳ
ＹがＨか否かを検出する。ステップ８１０でＡＢＳＹが
Ｌの場合はステップ８１５でＴＩＭＥＲが１．０ｓｅｃ
以上か否かを検出する。ここでＴＩＭＥＲはＡＢＳＹが
Ｌの時間を計測するタイマーである。ＴＩＭＥＲが１．
０ｓｅｃ未満の時は本処理を終了する。ＴＩＭＥＲが
１．０ｓｅｃ以上、ＡＢＳＹが連続で１．０ｓｅｃ以上
Ｌである時、即ちバス４００が所定時間以上アイドル状
態にならない時、バス異常を起こしたと判断してステッ
プ８２０で通信異常を示すフラグＸＦＡＩＬをセットし
本処理を終了する。
【００２３】一方、ステップ８１０でＡＢＳＹがＨの時
はステップ８２５でＴＩＭＥＲをリセットしてステップ
８３０に進む。ステップ８３０〜８６０は制御装置１０
０での通信データの送・受信処理を示している。ステッ
プ８３０でｎＤＡＴＡが０か否かを検出する。ｎＤＡＴ
Ａが０でない、即ち送信データがある場合はステップ８
３５に進む。ステップ８３５でｎＤＡＴＡが＄ＦＦか否
かを検出する。ｎＤＡＴＡが＄ＦＦでない場合はステッ
プ８４０に進む。一方、ｎＤＡＴＡが＄ＦＦである、即
ちＩＧＳＷ１７０がオンされたタイミングである場合は
ステップ８４０に進む。ステップ８４０で通信異常検出
処理を実行（詳細は後述の図１０）して本処理を終了す
る。
はステップ８２５でＴＩＭＥＲをリセットしてステップ
８３０に進む。ステップ８３０〜８６０は制御装置１０
０での通信データの送・受信処理を示している。ステッ
プ８３０でｎＤＡＴＡが０か否かを検出する。ｎＤＡＴ
Ａが０でない、即ち送信データがある場合はステップ８
３５に進む。ステップ８３５でｎＤＡＴＡが＄ＦＦか否
かを検出する。ｎＤＡＴＡが＄ＦＦでない場合はステッ
プ８４０に進む。一方、ｎＤＡＴＡが＄ＦＦである、即
ちＩＧＳＷ１７０がオンされたタイミングである場合は
ステップ８４０に進む。ステップ８４０で通信異常検出
処理を実行（詳細は後述の図１０）して本処理を終了す
る。
【００２４】ステップ８３０でｎＤＡＴＡが０、即ち送
信データがない場合はステップ８４５に進む。ステップ
８４５で診断装置３００からの送信データを処理する受
信ルーティンを実行する（詳細は後述の図１１）。ステ
ップ８５０でｎＤＡＴＡが０か否かを検出する。ｎＤＡ
ＴＡが０、即ち診断装置３００からの送信データがない
場合は本処理を終了する。
信データがない場合はステップ８４５に進む。ステップ
８４５で診断装置３００からの送信データを処理する受
信ルーティンを実行する（詳細は後述の図１１）。ステ
ップ８５０でｎＤＡＴＡが０か否かを検出する。ｎＤＡ
ＴＡが０、即ち診断装置３００からの送信データがない
場合は本処理を終了する。
【００２５】一方、ステップ８５０でｎＤＡＴＡが０で
ない、即ち診断装置３００からの送信データがある場合
はステップ８５５で送信データに基づく送信要求処理を
実行（詳細は後述の図１２）し、ステップ８６０に進
む。ステップ８６０で送信ルーティンを実行（詳細は後
述の図２２）し本処理を終了する。次に本発明の特徴で
ある通信異常検出の方法について述べる。
ない、即ち診断装置３００からの送信データがある場合
はステップ８５５で送信データに基づく送信要求処理を
実行（詳細は後述の図１２）し、ステップ８６０に進
む。ステップ８６０で送信ルーティンを実行（詳細は後
述の図２２）し本処理を終了する。次に本発明の特徴で
ある通信異常検出の方法について述べる。
【００２６】まず正常時にはＣＰＵ１１０から通信ＩＣ
１４０にデータを送信する場合、ＡＳＴＸをＬｏに立ち
下げ、ＴＸから順次データを通信ＩＣ１４０に送信す
る。通信ＩＣ１４０はＣＰＵ１１０から送信されるデー
タを順次バッファに蓄積していき、ＡＳＴＸがＨｉに立
ち上がった時点までのデータを１メッセージと判断し
て、バスへＴＸＪから１メッセージをまとめて送信す
る。
１４０にデータを送信する場合、ＡＳＴＸをＬｏに立ち
下げ、ＴＸから順次データを通信ＩＣ１４０に送信す
る。通信ＩＣ１４０はＣＰＵ１１０から送信されるデー
タを順次バッファに蓄積していき、ＡＳＴＸがＨｉに立
ち上がった時点までのデータを１メッセージと判断し
て、バスへＴＸＪから１メッセージをまとめて送信す
る。
【００２７】バスがグランドにショートした場合の異常
（第１異常）時は、通信ＩＣ１４０からバスへデータの
送信ができないため、ＡＢＳＹはＴＸＪからデータ送信
を実行後Ｈｉに立ち上がるが、ＡＳＴＸが立ち下がった
時点でバッファに送信ができなかったデータが存在する
ためＡＢＳＹはＬｏに立ち下がる。よって、通信ＩＣ１
４０がバスにデータ送信を実行したあと、ＡＳＴＸを立
ち下げたときのＡＢＳＹの状態がＬｏの場合は、バスが
グランドにショートしたとき第１異常と判断する。
（第１異常）時は、通信ＩＣ１４０からバスへデータの
送信ができないため、ＡＢＳＹはＴＸＪからデータ送信
を実行後Ｈｉに立ち上がるが、ＡＳＴＸが立ち下がった
時点でバッファに送信ができなかったデータが存在する
ためＡＢＳＹはＬｏに立ち下がる。よって、通信ＩＣ１
４０がバスにデータ送信を実行したあと、ＡＳＴＸを立
ち下げたときのＡＢＳＹの状態がＬｏの場合は、バスが
グランドにショートしたとき第１異常と判断する。
【００２８】ＣＰＵ１１０と通信ＩＣ１４０との間の信
号ラインがグランドにショートした場合の異常（第２異
常）時にはＣＰＵ１１０から通信ＩＣ１４０にデータは
送信されない。よって、ＣＰＵ１１０からデータを１バ
イト送信した時のＡＢＳＹの状態がＨｉの場合はＣＰＵ
１１０と通信ＩＣ１４０との間の信号ラインがグランド
にショートしたとき第２異常と判断する。
号ラインがグランドにショートした場合の異常（第２異
常）時にはＣＰＵ１１０から通信ＩＣ１４０にデータは
送信されない。よって、ＣＰＵ１１０からデータを１バ
イト送信した時のＡＢＳＹの状態がＨｉの場合はＣＰＵ
１１０と通信ＩＣ１４０との間の信号ラインがグランド
にショートしたとき第２異常と判断する。
【００２９】次に本発明の特徴である作動を図１０を用
いて説明する。図１０中（ａ）（ｂ）は図９のステップ
８４０の通信異常検出処理を示すフローチャートであ
る。まず、図１０中（ａ）のステップ９００で検査用の
ダミー送信データをＲＢＵＦ〔１１〕，ｎＤＡＴＡにセ
ットする。ダミー送信データとして本実施例では２バイ
トからなる送信データとし、ヘッダおよび所定値で構成
されるものとする。ステップ９０５で変数ｋに１をセッ
トする。ステップ９１０で通信ＩＣ１４０に対して通信
データを転送することを示すためにＡＳＴＸをＬｏに立
ち下げる。ステップ９１５でＲＢＵＦ〔ｋ〕１バイトを
通信ＩＣ１４０に送信する。
いて説明する。図１０中（ａ）（ｂ）は図９のステップ
８４０の通信異常検出処理を示すフローチャートであ
る。まず、図１０中（ａ）のステップ９００で検査用の
ダミー送信データをＲＢＵＦ〔１１〕，ｎＤＡＴＡにセ
ットする。ダミー送信データとして本実施例では２バイ
トからなる送信データとし、ヘッダおよび所定値で構成
されるものとする。ステップ９０５で変数ｋに１をセッ
トする。ステップ９１０で通信ＩＣ１４０に対して通信
データを転送することを示すためにＡＳＴＸをＬｏに立
ち下げる。ステップ９１５でＲＢＵＦ〔ｋ〕１バイトを
通信ＩＣ１４０に送信する。
【００３０】ステップ９２０で変数ｋが１か否かを検出
する。変数ｋが１でない、即ちダミー送信データの２バ
イト目を転送したタイミングである場合はステップ９３
０に進む。一方、変数ｋが１、即ちダミー送信データの
１バイト目を転送したタイミングである場合はステップ
９２５でＡＢＳＹの状態がＬｏか否かを検出する。ＡＢ
ＳＹがＨｉの場合は通信異常であると判断して（第２異
常判断手段）、図１０中（ｂ）のステップ９６０に進
む。ＡＢＳＹがＬｏの場合はステップ９３０に進む。ス
テップ９３０にて変数ｋをインクリメント（ｋ←ｋ＋
１）し、ステップ９３５に進む。ステップ９３５ではｎ
ＤＡＴＡと変数ｋを比較し、ｎＤＡＴＡが変数ｋより大
きい場合はステップ９１５に戻る。ｎＤＡＴＡが変数ｋ
より大きくない場合はステップ９４０に進み、ステップ
９４０で通信ＩＣ１４０に対して送信データの転送が終
了したことを示すためにＡＳＴＸをＨｉに立ち上げ、図
１０中（ｂ）のステップ９４５に進む。
する。変数ｋが１でない、即ちダミー送信データの２バ
イト目を転送したタイミングである場合はステップ９３
０に進む。一方、変数ｋが１、即ちダミー送信データの
１バイト目を転送したタイミングである場合はステップ
９２５でＡＢＳＹの状態がＬｏか否かを検出する。ＡＢ
ＳＹがＨｉの場合は通信異常であると判断して（第２異
常判断手段）、図１０中（ｂ）のステップ９６０に進
む。ＡＢＳＹがＬｏの場合はステップ９３０に進む。ス
テップ９３０にて変数ｋをインクリメント（ｋ←ｋ＋
１）し、ステップ９３５に進む。ステップ９３５ではｎ
ＤＡＴＡと変数ｋを比較し、ｎＤＡＴＡが変数ｋより大
きい場合はステップ９１５に戻る。ｎＤＡＴＡが変数ｋ
より大きくない場合はステップ９４０に進み、ステップ
９４０で通信ＩＣ１４０に対して送信データの転送が終
了したことを示すためにＡＳＴＸをＨｉに立ち上げ、図
１０中（ｂ）のステップ９４５に進む。
【００３１】ステップ９４５で通信ＩＣ１４０に転送し
た送信データがドライバ／レシーバ１４５を介してバス
４００へ送信されるまでの所定時間ウェイトする。ステ
ップ９５０でＡＳＴＸをＬｏに立ち下げる。ステップ９
５５でＡＢＳＹがＬｏか否かを検出する。ＡＢＳＹがＬ
ｏの場合は通信異常であると判断して（第１異常判断手
段）、ステップ９６０に進む。ステップ９６０でＡＳＴ
ＸをＨｉに立ち上げ、ステップ９６５で通信異常フラグ
ＸＦＡＩＬをセットして本処理を終了する。
た送信データがドライバ／レシーバ１４５を介してバス
４００へ送信されるまでの所定時間ウェイトする。ステ
ップ９５０でＡＳＴＸをＬｏに立ち下げる。ステップ９
５５でＡＢＳＹがＬｏか否かを検出する。ＡＢＳＹがＬ
ｏの場合は通信異常であると判断して（第１異常判断手
段）、ステップ９６０に進む。ステップ９６０でＡＳＴ
ＸをＨｉに立ち上げ、ステップ９６５で通信異常フラグ
ＸＦＡＩＬをセットして本処理を終了する。
【００３２】一方、ステップ９５５でＡＢＳＹがＨｉの
場合は、通信異常ではないと判断してステップ９７０に
進む。ステップ９７０でＡＳＴＸをＨｉに立ち上げ、ス
テップ９７５で通信異常フラグＸＦＡＩＬをリセットし
本処理を終了する。ＡＢＳＹはＣＰＵ１１０から送信デ
ータの１バイト目を受信した時点でＬｏに立ち下がり、
送信データを全てバス４００に送信した時点で立ち下げ
る。
場合は、通信異常ではないと判断してステップ９７０に
進む。ステップ９７０でＡＳＴＸをＨｉに立ち上げ、ス
テップ９７５で通信異常フラグＸＦＡＩＬをリセットし
本処理を終了する。ＡＢＳＹはＣＰＵ１１０から送信デ
ータの１バイト目を受信した時点でＬｏに立ち下がり、
送信データを全てバス４００に送信した時点で立ち下げ
る。
【００３３】図１１は図９のステップ８４５の受信ルー
ティン処理を示すフローチャートである。まずステップ
１０００で受信データのメッセージ長を検出するための
変数ｋを０にセットする。ステップ１０１０でＡＲＴＳ
がＬｏか否かを検出する。ＡＲＴＳがＨ、即ち通信ＩＣ
１４０にて診断装置３００からの受信データがない場合
はステップ１０５０に進む。
ティン処理を示すフローチャートである。まずステップ
１０００で受信データのメッセージ長を検出するための
変数ｋを０にセットする。ステップ１０１０でＡＲＴＳ
がＬｏか否かを検出する。ＡＲＴＳがＨ、即ち通信ＩＣ
１４０にて診断装置３００からの受信データがない場合
はステップ１０５０に進む。
【００３４】一方、ステップ１０１０でＡＲＴＳがＬ
ｏ、即ち通信ＩＣ１４０にて診断装置３００からの受信
データがある場合はステップ１０２０〜１０４０で受信
データをＲＢＵＦ〔１１〕にセットする処理を実行す
る。ステップ１０２０で変数ｋをインクリメントする。
ステップ１０３０でＲＢＵＦ〔ｋ〕に受信データを１バ
イト取込む。ステップ１０４０でＡＲＴＳはＨｉか否か
を検出する。ＡＲＴＳがＬｏ、即ち受信データがまだあ
る場合はステップ１０２０に進み、ステップ１０２０〜
１０４０の処理を再度実行する。一方、ＡＲＴＳがＨ
ｉ、即ち受信データがない場合はステップ１０５０に進
む。
ｏ、即ち通信ＩＣ１４０にて診断装置３００からの受信
データがある場合はステップ１０２０〜１０４０で受信
データをＲＢＵＦ〔１１〕にセットする処理を実行す
る。ステップ１０２０で変数ｋをインクリメントする。
ステップ１０３０でＲＢＵＦ〔ｋ〕に受信データを１バ
イト取込む。ステップ１０４０でＡＲＴＳはＨｉか否か
を検出する。ＡＲＴＳがＬｏ、即ち受信データがまだあ
る場合はステップ１０２０に進み、ステップ１０２０〜
１０４０の処理を再度実行する。一方、ＡＲＴＳがＨ
ｉ、即ち受信データがない場合はステップ１０５０に進
む。
【００３５】ステップ１０５０で変数ｋを受信データの
メッセージ長としてｎＤＡＴＡにセットし本処理を終了
する。図１２は図９のステップ８５５の応答処理を示す
フローチャートである。まずステップ１１００で診断装
置３００からの要求の種類を検出する。診断装置３００
より送信されたデータは図４中（１）（２）（３）に示
すように構成されているため、ヘッダの次のデータによ
り要求の種類を検出することができる。ヘッダの次のデ
ータが＄０３の時、即ちコード読出が要求されている場
合はステップ１１１０でコード読出要求処理を実行（詳
細は後述の図１３）し本処理を終了する。ヘッダの次の
データが＄０４の時、即ちコード消去が要求されている
場合はステップ１１２０でコード消去要求処理を実行
（詳細は後述の図１４）し本処理を終了する。ヘッダの
次のデータが＄Ａ４の時、即ちＲＡＭ値読出が要求され
ている場合はステップ１１３０でＲＡＭ値読出要求処理
を実行（詳細は後述の図１７）し本処理を終了する。
メッセージ長としてｎＤＡＴＡにセットし本処理を終了
する。図１２は図９のステップ８５５の応答処理を示す
フローチャートである。まずステップ１１００で診断装
置３００からの要求の種類を検出する。診断装置３００
より送信されたデータは図４中（１）（２）（３）に示
すように構成されているため、ヘッダの次のデータによ
り要求の種類を検出することができる。ヘッダの次のデ
ータが＄０３の時、即ちコード読出が要求されている場
合はステップ１１１０でコード読出要求処理を実行（詳
細は後述の図１３）し本処理を終了する。ヘッダの次の
データが＄０４の時、即ちコード消去が要求されている
場合はステップ１１２０でコード消去要求処理を実行
（詳細は後述の図１４）し本処理を終了する。ヘッダの
次のデータが＄Ａ４の時、即ちＲＡＭ値読出が要求され
ている場合はステップ１１３０でＲＡＭ値読出要求処理
を実行（詳細は後述の図１７）し本処理を終了する。
【００３６】図１３は図１２のステップ１１１０のコー
ド読出要求処理を示すフローチャートであり所定周期毎
に起動される。まずステップ１１５０で現在コード消去
を実行中か否かを検出する。詳細には、後述する図１５
の処理による、カウンタＣＮＴのカウント値が５００ｍ
ｓｅｃ以上か否かで検出する。カウンタＣＮＴのカウン
ト値が５００ｍｓｅｃ以下の場合、即ちコード消去実行
中である場合はステップ１１６０で「異常コードなし」
と言う情報、即ちコード消去後の情報に対応するコード
をＲＢＵＦ〔１１〕にセットし本処理を終了する。一
方、カウンタＣＮＴのカウント値が５００ｍｓｅｃ以上
の場合、即ちコード消去実行中でない場合はステップ１
１７０でＳＲＡＭ領域に記憶されているＣＰＵ１１
０で検出したダイアグコードおよびＤＭＡ領域に記憶
されているＣＰＵ１２０、１３０で検出したダイアグコ
ードをサーチしてその結果に対応するコードをＲＢＵＦ
〔１１〕にセットし本処理を終了する。
ド読出要求処理を示すフローチャートであり所定周期毎
に起動される。まずステップ１１５０で現在コード消去
を実行中か否かを検出する。詳細には、後述する図１５
の処理による、カウンタＣＮＴのカウント値が５００ｍ
ｓｅｃ以上か否かで検出する。カウンタＣＮＴのカウン
ト値が５００ｍｓｅｃ以下の場合、即ちコード消去実行
中である場合はステップ１１６０で「異常コードなし」
と言う情報、即ちコード消去後の情報に対応するコード
をＲＢＵＦ〔１１〕にセットし本処理を終了する。一
方、カウンタＣＮＴのカウント値が５００ｍｓｅｃ以上
の場合、即ちコード消去実行中でない場合はステップ１
１７０でＳＲＡＭ領域に記憶されているＣＰＵ１１
０で検出したダイアグコードおよびＤＭＡ領域に記憶
されているＣＰＵ１２０、１３０で検出したダイアグコ
ードをサーチしてその結果に対応するコードをＲＢＵＦ
〔１１〕にセットし本処理を終了する。
【００３７】図１４は図１２のステップ１１２０のコー
ド消去要求処理を示すフローチャートであり、所定周期
（例えば６５ｍｓｅｃ）毎に起動される。まずステップ
１２００で今回の起動がコード消去要求があってから１
回目の起動か否かを検出する。詳細には、診断装置３０
０からの送信データが図４中（２）に示すような構成で
有るか否かにより検出する。１回目の起動でない場合は
ステップ１２３０へ進む。
ド消去要求処理を示すフローチャートであり、所定周期
（例えば６５ｍｓｅｃ）毎に起動される。まずステップ
１２００で今回の起動がコード消去要求があってから１
回目の起動か否かを検出する。詳細には、診断装置３０
０からの送信データが図４中（２）に示すような構成で
有るか否かにより検出する。１回目の起動でない場合は
ステップ１２３０へ進む。
【００３８】１回目の起動であると検出された場合はス
テップ１２１０で、診断装置３００にコード消去要求を
受信したことを応答するための受信コードを、ＲＢＵＦ
〔１１〕にセットしステップ１２２０に進む。ステップ
１２２０でコード消去開始からの経過時間をカウントす
るカウンタＣＮＴをクリアし、ステップ１２３０に進
む。
テップ１２１０で、診断装置３００にコード消去要求を
受信したことを応答するための受信コードを、ＲＢＵＦ
〔１１〕にセットしステップ１２２０に進む。ステップ
１２２０でコード消去開始からの経過時間をカウントす
るカウンタＣＮＴをクリアし、ステップ１２３０に進
む。
【００３９】ステップ１２３０でカウンタＣＮＴのカウ
ント値が５００ｍｓｅｃ以上か否かを検出する。カウン
タＣＮＴのカウント値が５００ｍｓｅｃ以下の場合、即
ち他のＣＰＵ１２０、１３０のコード消去が実行中であ
ると判断した場合は、ステップ１２４０で低電圧状態で
あるか否かを検出する。低電圧状態でない場合はステッ
プ１２６０に進む。低電圧状態の場合はステップ１２５
０でカウンタＣＮＴをクリアしステップ１２６０に進
む。ここで、本実施例では前述のように（図５参考）低
電圧状態の場合はＳＲＡＭ領域のデータ更新に誤動
作を生じる可能性がありデータ更新を禁止しているため
カウンタＣＮＴをクリアする。
ント値が５００ｍｓｅｃ以上か否かを検出する。カウン
タＣＮＴのカウント値が５００ｍｓｅｃ以下の場合、即
ち他のＣＰＵ１２０、１３０のコード消去が実行中であ
ると判断した場合は、ステップ１２４０で低電圧状態で
あるか否かを検出する。低電圧状態でない場合はステッ
プ１２６０に進む。低電圧状態の場合はステップ１２５
０でカウンタＣＮＴをクリアしステップ１２６０に進
む。ここで、本実施例では前述のように（図５参考）低
電圧状態の場合はＳＲＡＭ領域のデータ更新に誤動
作を生じる可能性がありデータ更新を禁止しているため
カウンタＣＮＴをクリアする。
【００４０】ステップ１２６０でＣＰＵ１１０に記憶さ
れているコードの消去を実行する。ステップ１２７０で
他のＣＰＵ１２０、１３０にコード消去要求を送信し本
処理を終了する。詳細にはＤＭＡ領域の所定アドレス
にコード消去要求を示すデータを書き込む。ステップ１
２３０でカウンタＣＮＴのカウント値が５００ｍｓｅｃ
以上の場合、即ち他のＣＰＵ１２０、１３０のコード消
去が完了したと判断した場合はステップ１２８０でＤＭ
Ａ領域の所定アドレスに書き込まれているコード消去
要求をクリアして本処理を終了する。
れているコードの消去を実行する。ステップ１２７０で
他のＣＰＵ１２０、１３０にコード消去要求を送信し本
処理を終了する。詳細にはＤＭＡ領域の所定アドレス
にコード消去要求を示すデータを書き込む。ステップ１
２３０でカウンタＣＮＴのカウント値が５００ｍｓｅｃ
以上の場合、即ち他のＣＰＵ１２０、１３０のコード消
去が完了したと判断した場合はステップ１２８０でＤＭ
Ａ領域の所定アドレスに書き込まれているコード消去
要求をクリアして本処理を終了する。
【００４１】図１５は前述の図１３におけるカウンタＣ
ＮＴを所定周期（例えば６５ｍｓｅｃ）でインクリメン
トする処理を示すフローチャートである。ステップ１３
００でカウンタＣＮＴをインクリメント（ＣＮＴ←ＣＮ
Ｔ＋１）して本処理を終了する。図１６はＣＰＵ１１０
からのコード消去要求に対して他のＣＰＵ１２０、１３
０で行うコード消去処理を示すフローチャートであり、
所定周期（例えば６５ｍｓｅｃ）毎に起動される。
ＮＴを所定周期（例えば６５ｍｓｅｃ）でインクリメン
トする処理を示すフローチャートである。ステップ１３
００でカウンタＣＮＴをインクリメント（ＣＮＴ←ＣＮ
Ｔ＋１）して本処理を終了する。図１６はＣＰＵ１１０
からのコード消去要求に対して他のＣＰＵ１２０、１３
０で行うコード消去処理を示すフローチャートであり、
所定周期（例えば６５ｍｓｅｃ）毎に起動される。
【００４２】ステップ１３１０でコード消去要求の有無
を検出する。詳細にはＣＰＵ１１０から送信されるＤＭ
Ａ領域の所定アドレスの値、すなわち、図１４のステッ
プ１２７０、ステップ１２８０の結果を検出する。な
お、コード消去要求が無い場合は本処理を終了する。コ
ード消去要求がある場合はステップ１１２０でコード消
去を実行し本処理を終了する。
を検出する。詳細にはＣＰＵ１１０から送信されるＤＭ
Ａ領域の所定アドレスの値、すなわち、図１４のステッ
プ１２７０、ステップ１２８０の結果を検出する。な
お、コード消去要求が無い場合は本処理を終了する。コ
ード消去要求がある場合はステップ１１２０でコード消
去を実行し本処理を終了する。
【００４３】図１７は図１２のステップ１１３０のＲＡ
Ｍ値読出要求処理を示すフローチャートであり、所定周
期（例えば１６ｍｓｅｃ）毎に起動される。まずステッ
プ１６００で既に他のＲＡＭ値読出要求があり、そのデ
ータ入力待ちの状態であるか否かを検出する。データ入
力待ちの状態である場合はステップ１６７０に進む。デ
ータ入力待ちの状態で無い場合はステップ１６１０で今
回の起動タイミングにおいて診断装置３００からのＲＡ
Ｍ値読出要求があったか否かを検出する。今回の起動タ
イミングにおけるＲＡＭ値読出要求で無い場合は本処理
を終了する。
Ｍ値読出要求処理を示すフローチャートであり、所定周
期（例えば１６ｍｓｅｃ）毎に起動される。まずステッ
プ１６００で既に他のＲＡＭ値読出要求があり、そのデ
ータ入力待ちの状態であるか否かを検出する。データ入
力待ちの状態である場合はステップ１６７０に進む。デ
ータ入力待ちの状態で無い場合はステップ１６１０で今
回の起動タイミングにおいて診断装置３００からのＲＡ
Ｍ値読出要求があったか否かを検出する。今回の起動タ
イミングにおけるＲＡＭ値読出要求で無い場合は本処理
を終了する。
【００４４】ステップ１６１０で今回の起動タイミング
におけるＲＡＭ値読出要求がある場合はステップ１６２
０でＲＡＭ値読出要求の送信データの対象ＣＰＵの番
号、要求アドレス値が所定のフォーマットであるか否か
を検出する。所定のフォーマットで無い場合は診断装置
３００からの送信データの異常と判断して本処理を終了
する。
におけるＲＡＭ値読出要求がある場合はステップ１６２
０でＲＡＭ値読出要求の送信データの対象ＣＰＵの番
号、要求アドレス値が所定のフォーマットであるか否か
を検出する。所定のフォーマットで無い場合は診断装置
３００からの送信データの異常と判断して本処理を終了
する。
【００４５】所定のフォーマットである場合はステップ
１６３０でＲＡＭ値読出要求の対象ＣＰＵの番号がＣＰ
Ｕ１１０に対応する番号１であるか否かを検出する。ス
テップ１６３０で対象ＣＰＵの番号が１、即ち対象ＣＰ
ＵがＣＰＵ１１０である場合はステップ１６４０に進
み、要求されたアドレスのＲＡＭ値をＲＢＵＦ〔１１〕
にセットして本処理を終了する。
１６３０でＲＡＭ値読出要求の対象ＣＰＵの番号がＣＰ
Ｕ１１０に対応する番号１であるか否かを検出する。ス
テップ１６３０で対象ＣＰＵの番号が１、即ち対象ＣＰ
ＵがＣＰＵ１１０である場合はステップ１６４０に進
み、要求されたアドレスのＲＡＭ値をＲＢＵＦ〔１１〕
にセットして本処理を終了する。
【００４６】一方、ステップ１６３０で対象ＣＰＵの番
号が２又は３、即ち対象ＣＰＵがＣＰＵ１１０で無いと
判断された場合はステップ１６５０，１６６０でＣＰＵ
１２０、１３０へのＲＡＭ値読出要求を実行し、ステッ
プ１６７０に進む。ステップ１６７０でＣＰＵ１２０、
１３０からのＲＡＭ値の送信状況をチェックする（詳細
は後述の図１８）。
号が２又は３、即ち対象ＣＰＵがＣＰＵ１１０で無いと
判断された場合はステップ１６５０，１６６０でＣＰＵ
１２０、１３０へのＲＡＭ値読出要求を実行し、ステッ
プ１６７０に進む。ステップ１６７０でＣＰＵ１２０、
１３０からのＲＡＭ値の送信状況をチェックする（詳細
は後述の図１８）。
【００４７】図１８は図１７のステップ１６７０でＣＰ
Ｕ１２０、１３０からのＲＡＭ値の送信状況をチェック
する処理を示すフローチャートである。まずステップ１
７００で今回制御装置３００に応答するタイミングか否
かを検出する。詳細には、ステップ１７３０とステップ
１７７０にて、ＣＰＵ１１０からＣＰＵ１２０又はＣＰ
Ｕ１３０に要求したアドレス値と、ＣＰＵ１２０又はＣ
ＰＵ１３０からＣＰＵ１１０へ送信されたアドレス値と
が一致したタイミングである場合セットされるフラグＸ
Ａ４ＡＮＳの状態により検出する。
Ｕ１２０、１３０からのＲＡＭ値の送信状況をチェック
する処理を示すフローチャートである。まずステップ１
７００で今回制御装置３００に応答するタイミングか否
かを検出する。詳細には、ステップ１７３０とステップ
１７７０にて、ＣＰＵ１１０からＣＰＵ１２０又はＣＰ
Ｕ１３０に要求したアドレス値と、ＣＰＵ１２０又はＣ
ＰＵ１３０からＣＰＵ１１０へ送信されたアドレス値と
が一致したタイミングである場合セットされるフラグＸ
Ａ４ＡＮＳの状態により検出する。
【００４８】フラグＸＡ４ＡＮＳ＝０、即ち今回制御装
置３００に応答するタイミングで無い場合は、ステップ
１７１０で要求したアドレス値と送信されたアドレス値
とをチェックする。ステップ１７２０で要求したアドレ
ス値と送信されたアドレス値とが一致しているか否かを
検出する。一致していない場合はステップ１７７０に進
む。一致している場合はステップ１７３０で前述のフラ
グＸＡ４ＡＮＳをセットし本処理を終了する。
置３００に応答するタイミングで無い場合は、ステップ
１７１０で要求したアドレス値と送信されたアドレス値
とをチェックする。ステップ１７２０で要求したアドレ
ス値と送信されたアドレス値とが一致しているか否かを
検出する。一致していない場合はステップ１７７０に進
む。一致している場合はステップ１７３０で前述のフラ
グＸＡ４ＡＮＳをセットし本処理を終了する。
【００４９】ステップ１７００でフラグＸＡ４ＡＮＳ＝
１、即ち要求したアドレス値と送信されたアドレス値と
が一致してから所定期間（例えば１６ｍｓｅｃ）経過し
ていて今回制御装置３００に応答するタイミングである
場合はステップ１７４０に進む。ステップ１７４０で対
象ＣＰＵからの受信したＲＡＭ値をＲＢＵＦ〔１１〕に
セットする。ステップ１７５０でＤＭＡ領域の要求ア
ドレス送信領域をクリアしステップ１７７０に進む。
１、即ち要求したアドレス値と送信されたアドレス値と
が一致してから所定期間（例えば１６ｍｓｅｃ）経過し
ていて今回制御装置３００に応答するタイミングである
場合はステップ１７４０に進む。ステップ１７４０で対
象ＣＰＵからの受信したＲＡＭ値をＲＢＵＦ〔１１〕に
セットする。ステップ１７５０でＤＭＡ領域の要求ア
ドレス送信領域をクリアしステップ１７７０に進む。
【００５０】ステップ１７７０でフラグＸＡ４ＡＮＳを
リセットし本処理を終了する。図１９は、図３のステッ
プ５４０におけるＣＰＵ１１０からのＲＡＭ値読出要求
に対するＣＰＵ１２０、１３０での処理を示すフローチ
ャートであり、所定周期（例えば１６ｍｓｅｃ）毎に起
動される。なお、ＣＰＵ１２０、１３０でも同じ処理が
実行される。
リセットし本処理を終了する。図１９は、図３のステッ
プ５４０におけるＣＰＵ１１０からのＲＡＭ値読出要求
に対するＣＰＵ１２０、１３０での処理を示すフローチ
ャートであり、所定周期（例えば１６ｍｓｅｃ）毎に起
動される。なお、ＣＰＵ１２０、１３０でも同じ処理が
実行される。
【００５１】まずステップ１８００でＲＡＭ値読出要求
の有無を検出する。詳細にはＤＭＡ領域の所定のアド
レスにＲＡＭ値読出要求を示す要求アドレスがＣＰＵ１
１０から送信されているか否かにより検出する。つまり
ここでは要求アドレスが＄００００の時ＲＡＭ値読出要
求無しと判断する。ここで要求アドレスが＄００００、
即ちＲＡＭ値読出要求が無い場合は本処理を終了する。
の有無を検出する。詳細にはＤＭＡ領域の所定のアド
レスにＲＡＭ値読出要求を示す要求アドレスがＣＰＵ１
１０から送信されているか否かにより検出する。つまり
ここでは要求アドレスが＄００００の時ＲＡＭ値読出要
求無しと判断する。ここで要求アドレスが＄００００、
即ちＲＡＭ値読出要求が無い場合は本処理を終了する。
【００５２】ステップ１８００にて要求アドレスが＄０
０００以外の場合、即ちＲＡＭ値読出要求が有る場合は
ステップ１８１０、１８２０でＣＰＵ１１０への送信処
理を行う。ステップ１８１０で要求アドレスのＲＡＭ値
を、後述する図２０に示すＤＭＡ領域に書き込む。即
ち、データ（Ｈ）、データ（Ｌ）を書き込む。ステップ
１８２０で要求アドレス値をＤＭＡ領域に書き込む。
即ち、アドレス（Ｈ）、アドレス（Ｌ）を書き込み本処
理を終了する。
０００以外の場合、即ちＲＡＭ値読出要求が有る場合は
ステップ１８１０、１８２０でＣＰＵ１１０への送信処
理を行う。ステップ１８１０で要求アドレスのＲＡＭ値
を、後述する図２０に示すＤＭＡ領域に書き込む。即
ち、データ（Ｈ）、データ（Ｌ）を書き込む。ステップ
１８２０で要求アドレス値をＤＭＡ領域に書き込む。
即ち、アドレス（Ｈ）、アドレス（Ｌ）を書き込み本処
理を終了する。
【００５３】図２０はＲＡＭ値読出要求に対するＣＰＵ
１１０への送信を行うＤＭＡ領域の割付けを示す。こ
の割付けではＤＭＡにより所定周期（例えば４ｍｓｅ
ｃ）毎にアドレス（Ｈ）、アドレス（Ｌ）、データ
（Ｈ）、データ（Ｌ）の順でＣＰＵ１１０に送信され
る。（Ｈ）は１６ビットデータの上位８ビットを示し、
（Ｌ）は１６ビットデータの下位８ビットを示す。
１１０への送信を行うＤＭＡ領域の割付けを示す。こ
の割付けではＤＭＡにより所定周期（例えば４ｍｓｅ
ｃ）毎にアドレス（Ｈ）、アドレス（Ｌ）、データ
（Ｈ）、データ（Ｌ）の順でＣＰＵ１１０に送信され
る。（Ｈ）は１６ビットデータの上位８ビットを示し、
（Ｌ）は１６ビットデータの下位８ビットを示す。
【００５４】次に各ＣＰＵ１１０、１２０、１３０での
ＤＭＡ通信に関する処理を説明する。図２１は各ＣＰＵ
１１０、１２０、１３０で実行されるＤＭＡ通信に関す
るソフトウェアでの処理を示すフローチャートであり、
所定周期（例えば４ｍｓｅｃ）毎に起動される。
ＤＭＡ通信に関する処理を説明する。図２１は各ＣＰＵ
１１０、１２０、１３０で実行されるＤＭＡ通信に関す
るソフトウェアでの処理を示すフローチャートであり、
所定周期（例えば４ｍｓｅｃ）毎に起動される。
【００５５】ステップ１９００でＤＭＡ通信の起動処理
を行い本処理を終了する。詳細にはＤＭＡ領域の先頭
アドレスをＤＭＡ通信のポインタに設定する。実際のＤ
ＭＡ通信においてソフトウェアが関与する部分はＤＭＡ
通信を起動するのみで、起動後はハードウェアによりＤ
ＭＡ領域のデータを順次他のＣＰＵに送信する。
を行い本処理を終了する。詳細にはＤＭＡ領域の先頭
アドレスをＤＭＡ通信のポインタに設定する。実際のＤ
ＭＡ通信においてソフトウェアが関与する部分はＤＭＡ
通信を起動するのみで、起動後はハードウェアによりＤ
ＭＡ領域のデータを順次他のＣＰＵに送信する。
【００５６】図２２は図９のステップ８６０の送信ルー
ティン処理を示すフローチャートである。ステップ２０
００でｎＤＡＴＡが０か否かを検出する。ｎＤＡＴＡが
０、即ち診断装置３００への送信データがない場合は本
処理を終了する。ｎＤＡＴＡが０でない、即ち診断装置
３００への送信データがある場合はステップ２０１０〜
２０８０の送信処理を実行する。
ティン処理を示すフローチャートである。ステップ２０
００でｎＤＡＴＡが０か否かを検出する。ｎＤＡＴＡが
０、即ち診断装置３００への送信データがない場合は本
処理を終了する。ｎＤＡＴＡが０でない、即ち診断装置
３００への送信データがある場合はステップ２０１０〜
２０８０の送信処理を実行する。
【００５７】ステップ２０１０でＡＳＴＸをＬｏに立ち
下げる。ステップ２０２０で今回の制御タイミングでＲ
ＢＵＦ〔１１〕から通信ＩＣ１４０へ転送した送信デー
タのバイト数を管理するための変数ｋを０にセットす
る。ステップ２０３０でＡＢＳＹがＬｏか否かを検出す
る。ＡＢＳＹがＬｏの場合はステップ２０４０に進む。
つまりＡＢＳＹがＬｏの場合は通信ＩＣ１４０に送信デ
ータが転送できないため、今回の処理では通信ＩＣ１４
０への転送が中止される。
下げる。ステップ２０２０で今回の制御タイミングでＲ
ＢＵＦ〔１１〕から通信ＩＣ１４０へ転送した送信デー
タのバイト数を管理するための変数ｋを０にセットす
る。ステップ２０３０でＡＢＳＹがＬｏか否かを検出す
る。ＡＢＳＹがＬｏの場合はステップ２０４０に進む。
つまりＡＢＳＹがＬｏの場合は通信ＩＣ１４０に送信デ
ータが転送できないため、今回の処理では通信ＩＣ１４
０への転送が中止される。
【００５８】ＡＢＳＹがＨｉの場合はステップ２０４０
に進む。ステップ２０４０で変数ｋをインクリメント
（ｋ←ｋ＋１）する。ステップ２０５０で通信ＩＣ１４
０にＲＢＵＦ〔ｋ〕のデータを１バイト転送する。ステ
ップ２０６０で変数ｋとｎＤＡＴＡとを比較する。変数
ｋがｎＤＡＴＡ未満、即ちＲＢＵＦ〔１１〕の送信デー
タの転送が完了していない場合はステップ２０３０〜２
０６０の処理を再度実行する。変数ｋがｎＤＡＴＡ以
上、即ちＲＢＵＦ〔１１〕の送信データを全て通信ＩＣ
１４０への転送した場合はステップ２０７０に進む。
に進む。ステップ２０４０で変数ｋをインクリメント
（ｋ←ｋ＋１）する。ステップ２０５０で通信ＩＣ１４
０にＲＢＵＦ〔ｋ〕のデータを１バイト転送する。ステ
ップ２０６０で変数ｋとｎＤＡＴＡとを比較する。変数
ｋがｎＤＡＴＡ未満、即ちＲＢＵＦ〔１１〕の送信デー
タの転送が完了していない場合はステップ２０３０〜２
０６０の処理を再度実行する。変数ｋがｎＤＡＴＡ以
上、即ちＲＢＵＦ〔１１〕の送信データを全て通信ＩＣ
１４０への転送した場合はステップ２０７０に進む。
【００５９】ステップ２０７０でＡＳＴＬをＨｉに立ち
上げる。ステップ２０８０でｎＤＡＴＡから変数ｋを減
算した値をｎＤＡＴＡにセットする。この処理によりＲ
ＢＵＦ〔１１〕の送信データが全て転送された時はｎＤ
ＡＴＡを０となる。また、ステップ２０３０で転送処理
を途中で中止した場合は未転送データのメッセージ長が
ｎＤＡＴＡにセットされる。
上げる。ステップ２０８０でｎＤＡＴＡから変数ｋを減
算した値をｎＤＡＴＡにセットする。この処理によりＲ
ＢＵＦ〔１１〕の送信データが全て転送された時はｎＤ
ＡＴＡを０となる。また、ステップ２０３０で転送処理
を途中で中止した場合は未転送データのメッセージ長が
ｎＤＡＴＡにセットされる。
【００６０】以上説明したように前述の実施例では、図
１０中（ａ）（ｂ）に示すようにＣＰＵ１１０から通信
ＩＣ１４０への送信データを転送した後の所定タイミン
グにおける通信ＩＣ１４０のバッファの状態に応じて通
信異常を検出する。したがって、診断装置３００が制御
装置１００に接続されていない場合でも通信異常を検出
することができる。
１０中（ａ）（ｂ）に示すようにＣＰＵ１１０から通信
ＩＣ１４０への送信データを転送した後の所定タイミン
グにおける通信ＩＣ１４０のバッファの状態に応じて通
信異常を検出する。したがって、診断装置３００が制御
装置１００に接続されていない場合でも通信異常を検出
することができる。
【００６１】さらに、図１３に示すようにコード読出要
求時にコード消去実行中である場合はＳＲＡＭから異常
コードをサーチしてその結果を診断装置３００に送信す
るのではなく、コード消去後のデータ（異常コードな
し）を診断装置３００に送信する。したがって、コード
読出要求時にコード消去実行中である場合に消去前のデ
ータを診断装置３００に送信することを防止できる。
求時にコード消去実行中である場合はＳＲＡＭから異常
コードをサーチしてその結果を診断装置３００に送信す
るのではなく、コード消去後のデータ（異常コードな
し）を診断装置３００に送信する。したがって、コード
読出要求時にコード消去実行中である場合に消去前のデ
ータを診断装置３００に送信することを防止できる。
【００６２】また、図１７、１８に示すようにＣＰＵ１
１０からＣＰＵ１２０，１３０のＲＡＭ値を送信する場
合、ＣＰＵ１１０からＣＰＵ１２０、１３０への要求ア
ドレス値と、ＣＰＵ１２０、１３０からＣＰＵ１１０へ
の送信アドレス値とが一致してから所定期間後（１６ｍ
ｓ）に要求アドレスに対応したＲＡＭ値を診断装置３０
０へ送信する。したがって、診断装置３００へ間違った
ＲＡＭ値を送信することを確実に防止することができ
る。
１０からＣＰＵ１２０，１３０のＲＡＭ値を送信する場
合、ＣＰＵ１１０からＣＰＵ１２０、１３０への要求ア
ドレス値と、ＣＰＵ１２０、１３０からＣＰＵ１１０へ
の送信アドレス値とが一致してから所定期間後（１６ｍ
ｓ）に要求アドレスに対応したＲＡＭ値を診断装置３０
０へ送信する。したがって、診断装置３００へ間違った
ＲＡＭ値を送信することを確実に防止することができ
る。
【００６３】
【発明の効果】本発明によれば、診断装置が仮に制御装
置にされているか否かに関係なく、バッファ手段周辺の
通信体系の異常を検出できる。
置にされているか否かに関係なく、バッファ手段周辺の
通信体系の異常を検出できる。
【図１】本発明の一実施例における車両通信システムの
構成図。
構成図。
【図２】車両通信システムの制御装置のＣＰＵ１１０と
ＣＰＵ１２０とＣＰＵ１３０のＲＡＭ構成図。
ＣＰＵ１２０とＣＰＵ１３０のＲＡＭ構成図。
【図３】制御装置に記憶されている情報を読みだす場合
の診断装置での処理を示すフローチャート
の診断装置での処理を示すフローチャート
【図４】図３のステップ５２０とステップ５２０とステ
ップ５４０とにおける送信データの例を表した図
ップ５４０とにおける送信データの例を表した図
【図５】図６等の異常検出処理にて異常が検出された場
合、その異常に応じたダイアグコードをＳＲＡＭ領域へ
記憶させる処理を示すフローチャート
合、その異常に応じたダイアグコードをＳＲＡＭ領域へ
記憶させる処理を示すフローチャート
【図６】水温センサの異常検出処理を示すフローチャー
ト
ト
【図７】イグニションスイッチがオンされたときのみ制
御装置にて実行されるイニシャルルーティンを示すフロ
ーチャート
御装置にて実行されるイニシャルルーティンを示すフロ
ーチャート
【図８】図７のＲＢＵＦ〔１１〕とｎＤＡＴＡについて
説明した図
説明した図
【図９】制御装置での診断装置とのデータ送受信処理を
示すフローチャート
示すフローチャート
【図１０】図９のステップ８４０の通信異常検出処理を
示すフローチャート
示すフローチャート
【図１１】図９のステップ８４５の受信ルーティン処理
を示すフローチャート
を示すフローチャート
【図１２】図９のステップ８５５の応答処理を示すフロ
ーチャート
ーチャート
【図１３】図１２のステップ１１１０のコード読出要求
処理を示すフローチャート
処理を示すフローチャート
【図１４】図１２のステップ１１２０のコード消去要求
処理を示すフローチャート
処理を示すフローチャート
【図１５】図１３のカウンタＣＮＴをインクリメントす
る処理を示すフローチャート
る処理を示すフローチャート
【図１６】ＣＰＵ１１０からのコード消去要求に対して
ＣＰＵ１２０とＣＰＵ１３０とで行うコード消去処理を
示すフローチャート
ＣＰＵ１２０とＣＰＵ１３０とで行うコード消去処理を
示すフローチャート
【図１７】図１２のステップ１１３０のＲＡＭ値読出要
求処理を示すフローチャート
求処理を示すフローチャート
【図１８】図１７のステップ１６７０でＣＰＵ１２０と
ＣＰＵ１３０とからのＲＡＭ値の送信状況をチェックす
る処理を示すフローチャート
ＣＰＵ１３０とからのＲＡＭ値の送信状況をチェックす
る処理を示すフローチャート
【図１９】図３のステップ５４０におけるＣＰＵ１１０
からのＲＡＭ値読出要求に対するＣＰＵ１２０とＣＰＵ
１３０とでの処理を示すフローチャート
からのＲＡＭ値読出要求に対するＣＰＵ１２０とＣＰＵ
１３０とでの処理を示すフローチャート
【図２０】ＲＡＭ値読出要求に対するＣＰＵ１１０への
送信を行うＤＭＡ領域の割り付けを示す図
送信を行うＤＭＡ領域の割り付けを示す図
【図２１】ＣＰＵで実行されるＤＭＡ通信に関するソフ
トウエアでの処理を示すフローチャート
トウエアでの処理を示すフローチャート
【図２２】図９のステップ８６０の送信ルーティン処理
を示すフローチャート
を示すフローチャート
【図２３】本発明のクレーム対応図
１００ 制御装置 １１０ ＣＰＵ １２０ ＣＰＵ １３０ ＣＰＵ １４０ 通信ＩＣ １４５ ドライバ／レシーバ １５０ 電源ＩＣ １６０ 車載バッテリ １７０ イグニションスイッチ（ＩＧＳＷ） ２００ 制御装置 ３００ 診断装置 ４００ バス
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.6 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｇ０５Ｂ 23/02 Ｔ 7618−3Ｈ Ｈ０４Ｌ 12/40
Claims (3)
- 【請求項１】 車両の制御を行う制御装置が、車両の制
御状態を診断するために該制御装置にて処理されるデー
タの読出しをバスを介して行う診断装置を外部に接続可
能となっている車両用通信システムにおいて、 前記制御装置は、 前記診断装置へ送信する前記データを蓄積し、第１のタ
イミングで前記バスに送信するバッファ手段と、 第２のタイミングにおける前記バッファ手段に蓄積され
ている前記データの状態に応じて前記バッファ手段周辺
の通信異常を検出する通信異常検出手段とを備えること
を特徴とする車両用通信システムの異常検出装置。 - 【請求項２】 前記通信異常検出手段は、 前記バッファ手段から前記データを前記バスに送信後、
前記バッファ手段に前記データが蓄積されている場合、
第１の異常と判断する第１異常判断手段を備えることを
特徴とする請求項１記載の車両用通信システムの異常検
出装置。 - 【請求項３】 前記通信異常検出手段は、 前記データの１部を前記バッファ手段に送信後、前記バ
ッファ手段に前記データが蓄積されていない場合、第２
の異常と判断する第２異常判断手段を備えることを特徴
とする請求項１記載の車両用通信システムの異常検出装
置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24947393A JP3430579B2 (ja) | 1993-10-05 | 1993-10-05 | 車両用通信システムの異常検出装置 |
| US08/317,483 US5565856A (en) | 1993-10-05 | 1994-10-04 | Abnormality detecting device for vehicle communication system and method of using same |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24947393A JP3430579B2 (ja) | 1993-10-05 | 1993-10-05 | 車両用通信システムの異常検出装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07107564A true JPH07107564A (ja) | 1995-04-21 |
| JP3430579B2 JP3430579B2 (ja) | 2003-07-28 |
Family
ID=17193488
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP24947393A Expired - Lifetime JP3430579B2 (ja) | 1993-10-05 | 1993-10-05 | 車両用通信システムの異常検出装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5565856A (ja) |
| JP (1) | JP3430579B2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006224892A (ja) * | 2005-02-21 | 2006-08-31 | Fujitsu Ten Ltd | 車両用電子制御装置 |
| JP2010266279A (ja) * | 2009-05-13 | 2010-11-25 | Suzuki Motor Corp | 車両用通信制御装置 |
Families Citing this family (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3333378B2 (ja) * | 1996-02-05 | 2002-10-15 | 本田技研工業株式会社 | 車両診断方法および装置 |
| JPH09226482A (ja) * | 1996-02-28 | 1997-09-02 | Toyota Motor Corp | 車両用通信制御装置 |
| US6128285A (en) * | 1997-01-24 | 2000-10-03 | At&T Corp. | Monitoring of a packet telephony device via a control device |
| JPH10274602A (ja) * | 1997-03-31 | 1998-10-13 | Toyota Motor Corp | 車両用通信制御装置 |
| JPH10290251A (ja) * | 1997-04-15 | 1998-10-27 | Yazaki Corp | ネットワークにおける異常復旧装置 |
| US5961561A (en) * | 1997-08-14 | 1999-10-05 | Invacare Corporation | Method and apparatus for remote maintenance, troubleshooting, and repair of a motorized wheelchair |
| US6285931B1 (en) * | 1998-02-05 | 2001-09-04 | Denso Corporation | Vehicle information communication system and method capable of communicating with external management station |
| DE19839354A1 (de) * | 1998-08-28 | 2000-03-02 | Daimler Chrysler Ag | Fahrzeugkommunikationssystem |
| EP1171703B1 (de) * | 1999-04-21 | 2004-09-22 | Siemens Aktiengesellschaft | Steuervorrichtung für stellantriebe einer brennkraftmaschine |
| JP3485026B2 (ja) * | 1999-05-25 | 2004-01-13 | 三菱自動車工業株式会社 | 車両の自己診断装置 |
| US6169943B1 (en) * | 1999-07-14 | 2001-01-02 | Eaton Corporation | Motor vehicle diagnostic system using hand-held remote control |
| WO2001015960A1 (en) | 1999-08-31 | 2001-03-08 | Deltaglide, Inc. | Power-assist vehicle |
| US7040435B1 (en) * | 1999-11-17 | 2006-05-09 | Vehicle Enhancement Systems Inc. | Method for data communication between a vehicle and a remote terminal |
| JP4454772B2 (ja) * | 2000-03-17 | 2010-04-21 | 富士通マイクロエレクトロニクス株式会社 | 通信バスの異常検出装置とマイクロコンピュータ |
| US6735501B1 (en) * | 2000-03-30 | 2004-05-11 | Space Systems/Loral, Inc | Satellite commanding using remotely controlled modulation of satellite on-board telemetry parameters |
| US6946650B2 (en) * | 2002-03-04 | 2005-09-20 | Independence Technology, L.L.C. | Sensor |
| WO2005041041A2 (de) * | 2003-10-23 | 2005-05-06 | Siemens Aktiengesellschaft | Verfahren und anordnung zur laufzeitmessung von funktionen |
| US7945358B2 (en) | 2005-08-18 | 2011-05-17 | Environmental Systems Products Holdings Inc. | System and method for testing the integrity of a vehicle testing/diagnostic system |
| JP4492702B2 (ja) * | 2008-01-11 | 2010-06-30 | トヨタ自動車株式会社 | 異常検出装置 |
| DE102008024979B4 (de) * | 2008-05-23 | 2022-03-10 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz-System eines Kraftfahrzeugs und ein Verfahren zum Betrieb des Bordnetz-Systems |
| EP2264642B1 (en) * | 2009-06-02 | 2014-02-26 | Vodafone Holding GmbH | Data exchange with a man-machine-device using short range radio communication |
| CN102971515B (zh) * | 2010-07-08 | 2015-12-16 | 三菱电机株式会社 | 汽车用数据异常判定装置 |
| JP6020611B2 (ja) * | 2015-01-20 | 2016-11-02 | トヨタ自動車株式会社 | 車両データのリモート収集システム |
| CN109358591B (zh) | 2018-08-30 | 2020-03-13 | 百度在线网络技术（北京）有限公司 | 车辆故障处理方法、装置、设备及存储介质 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS59211143A (ja) * | 1983-05-17 | 1984-11-29 | Nissan Motor Co Ltd | マイクロコンピユ−タを用いた車両用制御回路 |
| JPH079388B2 (ja) * | 1988-02-29 | 1995-02-01 | 富士重工業株式会社 | 車輌診断システム |
| JPH0776737B2 (ja) * | 1988-10-21 | 1995-08-16 | 富士重工業株式会社 | 車輌診断システム |
| JPH0528091A (ja) * | 1991-07-23 | 1993-02-05 | Alps Electric Co Ltd | データ伝送装置 |
-
1993
- 1993-10-05 JP JP24947393A patent/JP3430579B2/ja not_active Expired - Lifetime
-
1994
- 1994-10-04 US US08/317,483 patent/US5565856A/en not_active Expired - Lifetime
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006224892A (ja) * | 2005-02-21 | 2006-08-31 | Fujitsu Ten Ltd | 車両用電子制御装置 |
| JP2010266279A (ja) * | 2009-05-13 | 2010-11-25 | Suzuki Motor Corp | 車両用通信制御装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| US5565856A (en) | 1996-10-15 |
| JP3430579B2 (ja) | 2003-07-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3430579B2 (ja) | 車両用通信システムの異常検出装置 | |
| EP0631213B1 (en) | Vehicle diagnosis system | |
| EP1839150B1 (en) | Fault diagnosis data recording system and method | |
| JP3138709B2 (ja) | 車両用電子制御装置の自己故障診断方法及び装置 | |
| JP2805970B2 (ja) | 車両用電子制御装置 | |
| US5737711A (en) | Diagnosis system for motor vehicle | |
| JP3491419B2 (ja) | 電子制御装置 | |
| US5459660A (en) | Circuit and method for interfacing with vehicle computer | |
| JP4061694B2 (ja) | 電子制御装置及び制御システム | |
| US20030200344A1 (en) | Vehicular communication device exchanging reception and transmission with external tool | |
| JP3491358B2 (ja) | 電源遮断検出装置 | |
| JP2003172199A (ja) | 車両用電子制御装置のプログラム書き換えシステム | |
| JP3203884B2 (ja) | 車両用診断システム | |
| JP3549712B2 (ja) | 自動車用制御装置のメモリ書込み方法及び自動車用制御装置 | |
| JP3179037B2 (ja) | 車両通信ネットワークシステム | |
| US20210065478A1 (en) | Electronic control unit and non-transitory computer readable medium storing session establishment program | |
| JPH0735648A (ja) | 車両用診断システム | |
| US6125456A (en) | Microcomputer with self-diagnostic unit | |
| JP2004142511A (ja) | 車両用電子制御装置，電子制御ユニット，プログラム及び記録媒体 | |
| JP3419060B2 (ja) | 車両用診断装置 | |
| US6907503B2 (en) | Dual port RAM communication protocol | |
| JP2003261018A (ja) | 車両用故障診断機構 | |
| JPH09172470A (ja) | 電子制御装置 | |
| JP3082525B2 (ja) | 制御装置 | |
| JP3004505B2 (ja) | 車両の管理システム装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20030422 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090523 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100523 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140523 Year of fee payment: 11 |
|
| EXPY | Cancellation because of completion of term |