JP6396873B2

JP6396873B2 - 電子制御装置及び診断方法

Info

Publication number: JP6396873B2
Application number: JP2015209878A
Authority: JP
Inventors: 拓也小林; 大輔古家
Original assignee: Hitachi Automotive Systems Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2015-10-26
Filing date: 2015-10-26
Publication date: 2018-09-26
Anticipated expiration: 2035-10-26
Also published as: JP2017084000A

Description

本発明は、自動車に搭載する電子制御装置及び診断方法に関する。

自動車の電子制御装置における機能安全のソフトウェア設計のコンセプトとして、プログラムを構成する複数のモジュールの機能安全の適用に関し、例えば、自動車用機能安全規格（ISO 26262）では、ハザードを評価する指標としてＡＳＩＬ（Automotive Safety Integrity Level）が提案されている。ＡＳＩＬでは、過酷度（Severity）、ハザードの発生頻度（probability of Exposure）、回避可能性（Controllability）等でクラス分けし、それに見合った設計レベルによる開発が要求されている。

また、自動車用機能安全規格では、ソフトウェアのシステムにおいて、設計レベルの違いにより安全関連部分と非安全関連部分とが混在する場合、自動車用機能安全規格のＦＦＩ（Freedom from Interference）に基づいて、互いに非干渉であることの保証が求められ、実質的に独立していなければならないことが要求される。

ここで、ＦＦＩに基づく独立性の実現手法の１つとして、例えば、安全関連部分のモジュール（セーフティモジュール（SM：Safety Module）ともいう。）においては、複数のモジュールの実行により所定の機能安全を発揮する場合、モジュール間の実行順序を監視することが望ましい。つまり、モジュールの実行順序が規定されている場合、想定した順序で実行されていることの検証が必要になる（特許文献１参照）。

特開２００１−１７５４９７号公報

しかし、モジュールの実行順序を評価する手段に異常が発生すると、本来ならば、実行順序が正常であるにも拘わらず、誤診断をする可能性が発生する。ここで、自動車の制御装置において、実行順序を評価する手段として、巡回冗長検査（ＣＲＣ：Cyclic Redundancy Check）の演算器（以下「ＣＲＣ演算器」という。）を用いた場合、当該ＣＲＣ演算器の動作保証が問題となる。

そこで、本発明は、上記問題点に鑑み、モジュールの実行順序を評価するためのＣＲＣ演算器に対して、動作保証を行なえる技術を提供することを目的とする。

本発明に係る電子制御装置は、複数のモジュールの実行順序が予め決められている制御プログラムを実行する自動車用の電子制御装置であって、上記モジュールの実行順序に従って付与された識別データを含む入力データに対して、上記識別データを用いた演算結果が反映されるＣＲＣ演算を順次施す演算処理を実行するＣＲＣ演算器と、上記演算処理により上記ＣＲＣ演算器が最終的に出力したＣＲＣ値と上記ＣＲＣ演算器を模擬したシミュレーションによる上記ＣＲＣ演算の出力値である基準値とを比較することにより、上記ＣＲＣ演算器が正常に動作するか否かを診断した上で、上記モジュールの実行順序が正しいか否かを診断する処理を実行する診断部と、を備える。
また、本発明に係る診断方法は、複数のモジュールの実行順序が予め決められている制御プログラムを実行する自動車用の電子制御装置の診断方法であって、上記モジュールの実行順序に従って付与された識別データを含む入力データに対して、上記識別データを用いた演算結果が反映されるＣＲＣ演算を順次施す演算処理を実行するＣＲＣ演算器が最終的に出力したＣＲＣ値と上記ＣＲＣ演算器を模擬したシミュレーションによる上記ＣＲＣ演算の出力値である基準値とを比較することにより、上記ＣＲＣ演算器が正常に動作するか否かを診断した上で、上記モジュールの実行順序が正しいか否かを診断する処理を実行する。

本発明によれば、上記ＣＲＣ演算器に対して上記診断処理を実行するので、上記ＣＲＣ演算器の動作保証を行なうことができる。

本実施形態におけるＥＣＵ（Electronic Control Unit）の構成例を示すブロック図である。本実施形態における制御プログラムの一例を示す説明図である。本実施形態の動作処理の概要を示す説明図である。本実施形態における診断方法の動作の一例を示すフローチャートである。ＣＲＣ演算プログラム用のサブルーチンの処理を示すフローチャートである。図５に示すフローチャートの流れを模式的に示した説明図である。ＣＲＣ演算器用のサブルーチンの処理を示すフローチャートである。図７に示すフローチャートの流れを模式的に示した説明図である。

以下、添付された図面を参照し、本発明を実施するための実施形態について詳述する。
[ＥＣＵの構成例]
図１は、本実施形態におけるＥＣＵの構成例を示すブロック図である。図１に示すＥＣＵ１は、自動車に搭載された各種の電子機器２０、例えば、電子制御式のスロットル弁、燃料噴射弁、変速機、電動ブレーキシステム、ＡＢＳ（Antilock Brake System）、可変バルブタイミング機構等（図示省略）を制御するものである。本実施形態では、説明の便宜上、各種の電子機器２０を１つのブロック図で表している。

図１に示す通り、ＥＣＵ１は、プロセッサ１１と、通信回路１２と、ＲＯＭ（Read Only Memory）１３と、ＲＡＭ（Random Access Memory）１４と、ＣＲＣ演算器１５と、バス１６と、を備える。プロセッサ１１、通信回路１２、ＲＯＭ１３、ＲＡＭ１４及びＣＲＣ演算器１５は、バス１６を介して、互いに接続されている。また、ＥＣＵ１は、通信回路１２を介して自動車のエンジンを制御する各種の電子機器２０と接続されている。

プロセッサ１１は、例えば、システムの中心的な処理を担うＣＰＵ（Central Processing Unit）であって、ＥＣＵ１の統括的な制御を行なうものである。また、プロセッサ１１は、モジュールの実行順序をＣＲＣ演算器１５で評価する前提として、所定規則でＣＲＣ演算を実行してＣＲＣ演算器１５が出力したＣＲＣ値と、予め定めた基準値とを比較することにより、そのＣＲＣ演算器１５が正常に動作するか否かを診断する診断処理を実行する診断部の一例としても機能する。
通信回路１２は、各種の電子機器２０に接続するための通信インターフェースを提供する。なお、通信回路１２は、例えば、ＣＡＮ（Controller Area Network）の通信プロトコルを実現するバスコントローラ（ＣＡＮコントローラ）を含んでいる。

ＲＯＭ１３は、例えば、フラッシュＲＯＭ等、電源（図示省略）からの電源供給を遮断してもデータが保持される不揮発性の半導体メモリである。ＲＡＭ１４は、例えば、演算処理等に用いられるデータの一時的な作業領域となるメモリであって、電源供給が遮断されると、記憶内容が消える揮発性メモリである。ＲＡＭ１４は、例えば、ダイナミックＲＡＭやスタティックＲＡＭであってもよい。なお、プロセッサ１１は、モジュールの実行順序を評価するために、ＣＲＣ演算器１５を模擬したシミュレーションによるＣＲＣ演算を実行するプログラム（以下「ＣＲＣ演算プログラム」という。）で処理する際、レジスタ（図示省略）を利用する。このレジスタは、ＲＡＭ１４に設けられてもよい。

ＣＲＣ演算器１５は、複数のモジュールの実行順序を評価するため、入力データに対して所定規則に従ってＣＲＣ演算を実行する演算器である。ＣＲＣ演算器１５は、例えば、ＣＲＣ演算専用のレジスタ（図示省略）を含み、巡回冗長検査用の電子回路を備える。但し、本実施形態では、ＣＲＣ演算器１５をモジュールの実行順序を評価する手段として用いる。ここで、所定規則とは、例えば、後述する図６、図８に示すような演算処理である。詳細については、フローチャート等を用いて説明する。バス１６は、例えば、ＣＡＮ通信のデータ転送等に利用することができる。

また、ＥＣＵ１は、プロセッサ１１、ＲＯＭ１３、ＲＡＭ１４、ＣＲＣ演算器１５等のハードウェアと、ＲＯＭ１３に記憶されている制御プログラムやＣＲＣ演算プログラム等のソフトウェアとが協働することにより、各種機能を実現する。この制御プログラムには、本実施形態の複数のモジュールが含まれる。したがって、プロセッサ１１は、制御プログラムを実行しているときに、本実施形態のＣＲＣ演算の処理を実現する。

図２は、本実施形態における制御プログラムの一例を示す説明図である。図２に示す制御プログラムＰ１は、例えば電子制御式のスロットル弁（図示省略）の制御に用いる。この制御プログラムＰ１は、スロットル弁の制御を実現するため、複数のモジュールＭ（１〜ｎ）から構成される。なお、説明を分かりやすくするため、ｎ＝４に簡略化した場合について例示する。具体的には、制御プログラムＰ１は、プロセッサ１１により実行され、アクセルポジションセンサ（ＡＰＳ：Accel Position Sensor）処理用のモジュールＭ１、スロットルポジションセンサ（ＴＰＳ：Throttle Position Sensor）処理用のモジュールＭ２、目標開度の演算処理用のモジュールＭ３、デューティ出力処理用のモジュールＭ４を含む。

ＡＰＳ処理用のモジュールＭ１は、アクセル開度（アクセルペダルの踏み込み量）を検出する処理を実行する。ＴＰＳ処理用のモジュールＭ２は、スロットル弁の実開度を検出する処理を実行する。目標開度の演算処理用のモジュールＭ３は、例えば、アクセル開度及びその変化量に基づいて、目標開度を演算する。デューティ出力処理用のモジュールＭ４は、スロットル弁の実開度と目標開度とを比較し、実開度と目標開度が一致するように、スロットル弁の開度を調節するモータの駆動デューティを求め、フィードバック制御により、スロットル弁の開度を調節する。

ここで、本実施形態では、安全関連部分に分類される複数のモジュールで構成される種々の制御プログラムにおいて、各モジュールに識別データを付与する。本実施形態では、一例として識別データをモジュールの実行順序に従ってシーケンスに付与する。例えば、識別データは、モジュールのプログラムに書き込まれている。ここで、制御プログラムＰ１の各モジュールの識別データＩＤ（ｎ）として、一例として、ＩＤ（１）＝１、ＩＤ（２）＝２、ＩＤ（３）＝３、ＩＤ（４）＝４とする。そして、本実施形態では、モジュールＭ１にＩＤ（１）、モジュールＭ２にＩＤ（２）、モジュールＭ３にＩＤ（３）、モジュールＭ４にＩＤ（４）を付与し、ＣＲＣ演算器１５を用いて、モジュールの実行順序が正しいか否かを診断する。以下、動作処理について説明をする。
[本実施形態の動作処理]

図３は、本実施形態の動作処理の概要を示す説明図である。以下の説明では、制御プログラムについては、スロットル弁の開度を調節する制御プログラムＰ１について適用するが、これに限定されるものではない。

本実施形態では、ＣＲＣ演算器１５の診断処理による故障検出の考え方として、例えば、ＥＣＵ１を起動させるときに、ＣＲＣ演算プログラムを利用して、ＣＲＣ演算器１５が正常に動作するか否かを診断する診断処理を実行する。

詳細には、例えば、イグニッションスイッチ（ＩＧＮＳＷ）がオンされると、ＥＣＵ１のプロセッサ１１は、ＥＣＵ１自体の起動に伴って、上記の診断処理を実行する。例えば、プロセッサ１１は、先ず、各種の電子機器２０を起動させるために必要な初期化処理を開始する。初期化処理が完了すると、続いて、プロセッサ１１は、上記の診断処理を実行する。つまり、本実施形態では、ＥＣＵ１を起動させ、初期化処理が完了した後、ＣＲＣ演算器１５の異常の有無を診断することができる。

より詳細には、プロセッサ１１は、先ず、プログラムの流れを監視するフローチェック対象の制御プログラムＰ１について、実行順序の確認処理として、実際の駆動制御を実行せずに、ＣＲＣ演算プログラムを実行する。そして、プロセッサ１１は、最終的に得られた演算結果のＣＲＣ値を第１の検証データとして求める。第１の検証データは、基準値の一例であって、ＣＲＣ演算プログラムが出力した値である。

さらに、プロセッサ１１は、ＣＲＣ演算プログラムと同一の手順で、ハードウェア（ＣＲＣ演算器１５）を利用してＣＲＣ演算を実行する。なお、同一の手順とは、実質的に同一の手順も含まれる。そして、プロセッサ１１は、最終的に得られた演算結果のＣＲＣ値を第２の検証データとして求める。プロセッサ１１は、第１の検証データと第２の検証データとが一致していれば、ＣＲＣ演算器１５が動作保証されていると判断する。一方、プロセッサ１１は、第１の検証データと第２の検証データとが不一致であれば、ＣＲＣ演算器１５に異常ありとして、例えば、警告表示により運転者に通知する処理を行なう。

そして、通常制御に移行すると、プロセッサ１１は、制御プログラムＰ１の各モジュールを実行する毎に、ＣＲＣ演算をＣＲＣ演算器１５にて実行する。これにより、ＣＲＣ演算の処理が高速化される。そして、プロセッサ１１は、キーオフによりイグニッションスイッチ（ＩＧＮＳＷ）がオフされ、シャットダウンをする終了処理に移行する前まで、フローチェックにより各モジュールの実行順序を監視する。そして、プロセッサ１１は、ＣＲＣ演算器１５が出力するＣＲＣ値に基づいて、ＣＲＣエラーが発生した場合には、例えば予め規定している異常発生時のフェールセーフ制御を実行する。

図４は、本実施形態における診断方法の動作の一例を示すフローチャートである。プロセッサ１１は、このフローチャートを初期化処理が完了すると実行する。なお、説明を分かりやすくするため、図２に示す制御プログラムＰ１を例示して以下説明を続ける。

ステップＳ１０１：プロセッサ１１は、ＣＲＣ演算プログラムに基づくＣＲＣ演算を実行するため、ＣＲＣ演算プログラム用のサブルーチンの処理に移行する。詳細は、図５を用いて後述する。
ステップＳ１０２：プロセッサ１１は、ＣＲＣ演算器１５にＣＲＣ演算を実行させるため、ＣＲＣ演算器１５用のサブルーチンの処理に移行する。詳細は、図７を用いて後述する。
ステップＳ１０３：プロセッサ１１は、演算結果の照合をする。
ステップＳ１０４：プロセッサ１１は、演算結果の照合に基づいて、ＣＲＣ演算器１５の異常の有無を判定する。ＣＲＣ演算器１５に異常ありと判定した場合（ステップＳ１０４：Ｙｅｓ）、ステップＳ１０５の処理に移行し、ＣＲＣ演算器１５に異常なしと判定した場合（ステップＳ１０４：Ｎｏ）、プロセッサ１１は、図４に示すフローチャートの処理を終了する。
ステップＳ１０５：プロセッサ１１は、ＣＲＣ演算器１５の異常時の処理を実行する。具体的には、プロセッサ１１は、一例として、スピードメータ内に設けられている警告灯（例えば、MIL（Multi function Indicator Lamp）点灯）をオン状態にし、運転者に、異常を知らせる。この場合、ＣＲＣ演算器１５に異常が認められたのであって、各種の電子機器２０に異常が発生したわけではない。したがって、プロセッサ１１は、プログラムによるフローチェック診断を停止させ、システム障害時における縮退運転には移行させないようにする。そして、プロセッサ１１は、図４に示すフローチャートの処理を終了する。

次に、ＣＲＣ演算プログラム用のサブルーチンの処理について説明をする。
図５は、ＣＲＣ演算プログラム用のサブルーチンの処理を示すフローチャートである。プロセッサ１１は、サブルーチンの処理を実行するに際し、ＣＲＣ演算プログラムの一例として、ＣＲＣ演算器１５の演算処理を代替するＣＲＣ演算プログラムＰ２を用いる。これにより、プロセッサ１１は、制御プログラムＰ１における最初のモジュールの識別データ及びＣＲＣ演算を開始するための初期値（以下「ＣＲＣ初期値」という。）に対して、巡回冗長検査における所定規則の演算を施し、その演算結果を求める。以下、詳細に説明する。

ステップＳ２０１：プロセッサ１１は、プログラムのループ処理用の変数ｎに０（ゼロ）を代入する。
ステップＳ２０２：プロセッサ１１は、ｎを、１ずつインクリメントする処理を実行する。

ステップＳ２０３：プロセッサ１１は、ｎ番目のモジュールについて、ＣＲＣ演算プログラムＰ２を実行する。具体的には、プロセッサ１１は、例えばｎ＝１の場合、１番目のモジュールの識別データ（ＩＤ（１））と、ＣＲＣ初期値とを入力データとして、ＣＲＣ演算プログラムＰ２を実行する。なお、ＣＲＣ演算プログラムＰ２のアルゴリズムは、誤り検出方式の一例であって、検査用のデータを値とみなして、所定の定数で割った余り（余剰）を用いて誤りの検知を行なう演算方法である。また、ＣＲＣ初期値は、例えば、任意のデータ列の値であってよい。

ここで、ＣＲＣ演算については、例えば、ＣＲＣ演算に用いる生成多項式に応じて様々な種類が公知であるが、本実施形態のように２つのパラメータ（識別データ、ＣＲＣ値（ｎ＝１の場合にはＣＲＣ初期値））からなる入力データに基づいて、毎回、ＣＲＣ値が求めることができれば、特に限定されない。なお、本実施形態では、演算負荷やＲＯＭ１３の容量を考慮して、例えば、生成多項式（Ｘ^１６＋Ｘ^１２＋Ｘ^５＋１）を採用することが好ましい。また、ＣＲＣ演算プログラムＰ２は、ＣＲＣ演算を実行することにより、演算結果のＣＲＣ値として、例えば、ｎ番目のモジュールについてＣＲＣ（ｎ）を求める。

ステップＳ２０４：プロセッサ１１は、ｎの値が制御プログラムＰ１のモジュールの総数に達したか否かを判定する。総数に達した場合（ステップＳ２０４：Ｙｅｓ）、ステップＳ２０５の処理に移行し、総数に達していない場合（ステップＳ２０４：Ｎｏ）、ステップＳ２０２の処理に戻り、ｎの値をインクリメント（ｎ＝ｎ＋１）する。
ステップＳ２０５：プロセッサ１１は、ＣＲＣ（ｎ）を、制御プログラムＰ１のモジュールの実行順序を評価する第１の検証データ（基準値）として求める。そして、プロセッサ１１は、その第１の検証データをＲＡＭ１４に記憶する。

図６は、図５に示すフローチャートの流れを模式的に示した説明図である。先ず、プロセッサ１１は、ＡＰＳ処理用のモジュールＭ１に対応する識別データ（ＩＤ（１））と、ＣＲＣ演算のＣＲＣ初期値とを入力データとして、ＣＲＣ演算プログラムＰ２を実行する。このＣＲＣ演算プログラムＰ２は、１回目の演算処理の演算結果として、ＣＲＣ（１）を求める。

次に、プロセッサ１１は、ＴＰＳ処理用のモジュールＭ２に対応する識別データ（ＩＤ（２））と、直前のＣＲＣ（ｎ−１）であるＣＲＣ（１）とを入力データとして、ＣＲＣ演算プログラムＰ２を実行する。ＣＲＣ演算プログラムＰ２は、２回目の演算処理の演算結果として、ＣＲＣ（２）を求める。

ここで、ＣＲＣ（１）には、ＡＰＳ処理に対応する識別データ（ＩＤ（１））を用いてＣＲＣ演算された結果が含まれている。さらに、ＣＲＣ（２）には、ＴＰＳ処理に対応する識別データ（ＩＤ（２））を用いてＣＲＣ演算された結果が含まれている。もし、ＣＲＣ演算の順序が逆の場合、ＣＲＣ（１）及びＣＲＣ（２）は、異なった値となる。

つまり、ＣＲＣ（１）には、ＡＰＳ処理に対応する識別データ（ＩＤ（１））を用いた演算結果が反映され、ＣＲＣ（２）には、ＡＰＳ処理に対応する識別データ（ＩＤ（１））を用いた演算結果のみならず、さらに、次の実行順序であるＴＰＳ処理に対応する識別データ（ＩＤ（２））を用いた演算結果が反映されている。

次に、プロセッサ１１は、目標開度の演算処理に対応する識別データ（ＩＤ（３））と、ＣＲＣ（２）とを入力データとして、ＣＲＣ演算プログラムＰ２を実行する。ＣＲＣ演算プログラムＰ２は、３回目の演算処理の演算結果として、ＣＲＣ（３）を求める。ＣＲＣ（３）は、ＣＲＣ（２）と比較して、さらに、次の実行順序である目標開度の演算処理に対応する識別データ（ＩＤ（３））を用いた演算結果が反映されている。

次に、プロセッサ１１は、デューティ出力処理に対応する識別データ（ＩＤ（４））と、ＣＲＣ（３）のデータとを入力データとして、ＣＲＣ演算プログラムＰ２を実行する。ＣＲＣ演算プログラムＰ２は、４回目の演算処理の演算結果として、ＣＲＣ（４）を求める。ＣＲＣ（４）は、ＣＲＣ（３）と比較して、さらに、次の実行順序であるデューティ出力処理に対応する識別データ（ＩＤ（４））を用いた演算結果が反映されている。

続いて、プロセッサ１１は、ＣＲＣ演算プログラムＰ２を終了すると、ＣＲＣ（４）をＲＡＭ１４に記憶する。ＣＲＣ（４）は、ＡＰＳ処理、ＴＰＳ処理、目標開度の演算処理、デューティ出力処理というように予め設定した実行順序を評価する第１の検証データとして利用することができる。つまり、本実施形態では、図４に示すフローチャートにて実行したＣＲＣ演算の最終結果のＣＲＣ（ｎ＝４）を第１の検証データとして利用する。

以上の処理をまとめると、プロセッサ１１は、制御プログラムＰ１における最初のモジュールの識別データ及びＣＲＣ初期値に対して、演算を施し、その演算結果を求める。続いて、プロセッサ１１は、制御プログラムＰ１の２番目以降の各モジュールについて、今回のモジュールの識別データ及び直前に実行したモジュールに係る演算結果に対してＣＲＣ演算を順次施す。このような演算処理が所定規則の一例である。そして、プロセッサ１１は、最終的に求められた演算結果を、第１の検証データとする。つまり、プロセッサ１１は、ＣＲＣ演算プログラムＰ２によるＣＲＣ演算により、第１の検証データを取得する。

なお、第１の検証データについては、予めＲＯＭ１３に記憶しておくようにしてもよい。この場合、図４に示す診断方法の動作の一例を示すフローチャートにおいて、プロセッサ１１は、ステップＳ１０１の処理をスキップして、ステップＳ１０３の演算結果の照合でＲＯＭ１３から第１の検証データを読み出すようにしてもよい。このようにすれば、プロセッサ１１は、毎回、ステップＳ１０１の処理にて、ＣＲＣ演算プログラム用のサブルーチンの処理を実行せずに済む。

次に、ＣＲＣ演算器１５用のサブルーチンの処理について説明する。
図７は、ＣＲＣ演算器１５用のサブルーチンの処理を示すフローチャートである。図７に示すフローチャートは、図５に示すフローチャートと比較して、ステップ２０３の処理とステップ３０３の処理とが、主に異なる。つまり、プロセッサ１１は、ＣＲＣ演算プログラムＰ２と同一の手順で、ＣＲＣ演算器１５でＣＲＣ演算を実行し、第２の検証データを求める。つまり、プロセッサ１１は、例えば、ＣＲＣ初期値を同一とし、同一の順番でモジュール毎に同一の識別データを適用して、ＣＲＣ演算を実行する。

ステップＳ３０１：プロセッサ１１は、プログラムのループカウンタ用の変数ｎに０（ゼロ）を代入する。
ステップＳ３０２：プロセッサ１１は、ｎを、１ずつインクリメントする処理を実行する。

ステップＳ３０３：プロセッサ１１は、ＣＲＣ演算プログラムＰ２と同一の手順で、モジュール毎に同じ入力データを入力して、ＣＲＣ演算器１５を用いてｎ番目のＣＲＣ演算を実行する。但し、ｎ＝１番目の場合には、ｎ―１番目のＣＲＣ値が存在しないので、ＣＲＣ初期値を入力する。ＣＲＣ演算器１５は、演算結果として、ＣＲＣ（ｎ）を出力する。

ステップＳ３０４：プロセッサ１１は、ｎの値が制御プログラムＰ１のモジュールの総数に達したか否かを判定する。総数に達した場合（ステップＳ３０４：Ｙｅｓ）、ステップＳ３０５の処理に移行し、総数に達していない場合（ステップＳ３０４：Ｎｏ）、ステップＳ３０２の処理に戻る。

ステップＳ３０５：プロセッサ１１は、第２の検証データを求める。そして、プロセッサ１１は、図７に示すフローチャートの処理を終了し、図４に示すステップＳ１０３の処理に戻る。

図８は、図７に示すフローチャートの流れを模式的に示した説明図である。先ず、プロセッサ１１は、先ず、ＡＰＳ処理（モジュールＭ１）に対応する識別データ（ＩＤ（１））と、ＣＲＣ初期値とを入力データとして、ＣＲＣ演算器１５に代入する。すると、ＣＲＣ演算器１５は、ＣＲＣ演算を実行し、１回目の演算結果としてＣＲＣ（１）を出力する。

次に、プロセッサ１１は、ＴＰＳ処理（モジュールＭ２）に対応する識別データ（ＩＤ（２））と、ＣＲＣ（１）とを入力データとして、ＣＲＣ演算器１５に代入する。すると、ＣＲＣ演算器１５は、ＣＲＣ演算を実行し、２回目の演算結果としてＣＲＣ（２）を出力する。

次に、プロセッサ１１は、目標開度の演算処理（モジュールＭ３）に対応する識別データ（ＩＤ（３））と、ＣＲＣ（２）のデータとを入力データとして、ＣＲＣ演算器１５に代入する。すると、ＣＲＣ演算器１５は、３回目の演算結果として、ＣＲＣ（３）を出力する。

次に、プロセッサ１１は、デューティ出力処理（モジュールＭ４）に対応する識別データ（ＩＤ（４））と、ＣＲＣ（３）とを入力データとして、ＣＲＣ演算器１５に代入する。すると、ＣＲＣ演算器１５は、４回目の演算結果として、ＣＲＣ（４）を出力する。これにより、プロセッサ１１は、図１に示すステップＳ１０３の処理において、演算結果の照合をすることができる。

ここで、自動車用機能安全規格では、例えば、故障を検出するための安全機構で発生する故障を検出するための指標（ＬＦＭ（Latent Failure Metrics））が示されている。故障を検出するための安全機構が故障した場合、運転の制御に直接には影響を及ぼさないものの、異常が検出できなくなる。そのため、故障を検出するための安全機構が正常に動作するか否かを診断する機能診断（以下「Latent機能診断」という。）を行なうことが好ましい。

本実施形態では、例えば、運転者がエンジンキーをオンした後、ＥＣＵ１の起動に伴って、ＣＲＣ演算器１５に対して、上述した診断処理（Latent機能診断の一例）を予め実行する。これにより、運転者は、故障を検出するための安全機構（ＣＲＣ演算器１５）における異常の有無を、上述した警告灯の表示の有無にて、すぐに知ることができる。

次に、通常制御時における診断処理の動作について説明する。プロセッサ１１は、図４に示すフローチャートの処理が異常なしで終了した後、キーオフ操作によりイグニッションスイッチ（ＩＧＮＳＷ）がオフされるまで、チェックフロー対象の制御プログラムＰ１を実行する毎に、モジュールの実行順序をチェックする。

具体的には、プロセッサ１１は、制御プログラムＰ１の最初のモジュールを実行する場合、そのモジュールの識別データ及びＣＲＣ初期値をＣＲＣ演算器１５に代入し、ＣＲＣ値を求める。そして、プロセッサ１１は、制御プログラムＰ１の２番目以降の各モジュールを実行する場合、モジュールの識別データ及び直前に実行したモジュールに係るＣＲＣ演算器１５から出力されたＣＲＣ値をそのＣＲＣ演算器１５に順次代入する。さらに、プロセッサ１１は、最後に実行したモジュールに係るＣＲＣ演算器１５から出力されたＣＲＣ値（第２の検証データ）と第１の検証データとの比較に基づいて、モジュールの実行順序を診断する。

ここで、プロセッサ１１は、全てのモジュールを実行した後、ＣＲＣ演算結果がエラーか否かを判定する。具体的には、プロセッサ１１は、第１の検証データと、最後のモジュールの実行後におけるＣＲＣ演算器１５が出力したＣＲＣ（ｎ）値（第２の検証データ）とを比較する。第１の検証データと第２の検証データとが一致しており、エラーでないと判定した場合、診断処理を終了し、再度、制御プログラムＰ１が実行されると、診断処理を再開する。

一方、第１の検証データと第２の検証データとが一致せず、エラーであると判定した場合、プロセッサ１１は、異常時の処理を実行する。プロセッサ１１は、例えば、予め規定している異常発生時のフェールセーフ制御を実行する。

なお、本実施形態では、例えば、ＥＣＵ１をメインのマイクロコンピュータとし、図示省略の他のＥＣＵをサブのマイクロコンピュータとする構成にしてもよい。この場合、ＣＲＣ演算器１５の演算結果を、サブのマイクロコンピュータに送信するようにして、サブのマイクロコンピュータ側で、エラーであるか否かの判定をし、エラーの場合には、異常発生時のフェールセーフ制御を実行するようにしてもよい。

以上より、本実施形態では、モジュールの実行順序を評価するためのＣＲＣ演算器１５に対して、上述した診断処理を実行することにより、動作保証を行なえる技術を提供できる。つまり、本実施形態では、ＣＲＣ演算プログラムＰ２とＣＲＣ演算器１５とに対して、同一の手順に従ってＣＲＣ演算を実行することで、容易に動作保証を行なえる。

[上記実施形態の補足事項]
上記実施形態では、説明を分かりやすくするため、モジュール数を４に限定して説明したが、上記実施形態では、モジュール数を２以上の任意の数に適用できる。つまり、上述した通り、制御プログラムの数やモジュール数の数が多くなるほど、プロセッサ１１の処理負荷を抑制でき、使用するＲＡＭ１４の使用率を抑制できる。また、上記実施形態では、所定時間経過しても、モジュールの総数分のモジュールが実行されない場合には、モジュールの実行漏れにより総数に達しないと判定し、フェールセーフ制御を実行するようにしてもよい。
上記実施形態では、例えば、ＥＣＵ１の起動に伴って、診断処理を実行したが、これに限定されず、例えば、定期的に診断処理を実行するようにしてもよいし、或いは、ＥＣＵ１を停止させるときに、診断処理を実行するようにしてもよい。すなわち、上記実施形態では、必要に応じて、診断処理のタイミングを設定してよい。

以上、本件に開示する実施形態について明細書及び図面等を用いて説明したが、本件開示の技術は、上記実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々の変更が可能である。

１…ＥＣＵ
１１…プロセッサ
１２…通信回路
１３…ＲＯＭ
１４…ＲＡＭ
１５…ＣＲＣ演算器
１６…バス
２０…電子機器
Ｐ１…制御プログラム
Ｐ２…ＣＲＣ演算プログラム

Claims

複数のモジュールの実行順序が予め決められている制御プログラムを実行する自動車用の電子制御装置であって、
前記モジュールの実行順序に従って付与された識別データを含む入力データに対して、前記識別データを用いた演算結果が反映されるＣＲＣ演算を順次施す演算処理を実行するＣＲＣ演算器と、
前記演算処理により前記ＣＲＣ演算器が最終的に出力したＣＲＣ値と、前記ＣＲＣ演算器を模擬したシミュレーションによる前記ＣＲＣ演算の出力値である基準値とを比較することにより、前記ＣＲＣ演算器が正常に動作するか否かを診断した上で、前記モジュールの実行順序が正しいか否かを診断する処理を実行する診断部と、
を備えることを特徴とする電子制御装置。
前記診断部は、電子制御装置自体の起動に伴って、前記診断処理を実行することを特徴とする請求項１に記載の電子制御装置。
複数のモジュールの実行順序が予め決められている制御プログラムを実行する自動車用の電子制御装置の診断方法であって、
前記モジュールの実行順序に従って付与された識別データを含む入力データに対して、前記識別データを用いた演算結果が反映されるＣＲＣ演算を順次施す演算処理を実行するＣＲＣ演算器が最終的に出力したＣＲＣ値と、前記ＣＲＣ演算器を模擬したシミュレーションによる前記ＣＲＣ演算の出力値である基準値とを比較することにより、前記ＣＲＣ演算器が正常に動作するか否かを診断した上で、前記モジュールの実行順序が正しいか否かを診断する処理を実行する診断方法。