JP4496205B2 - 制御用マイクロコンピュータの検証装置および車載用制御装置 - Google Patents

Description

本発明は、制御用マイクロコンピュータの検証装置および車載用制御装置に係り、特に、マイクロコンピュータにより逐次実行される制御ソフトウェアによる状態遷移をアサーションベース方式で検証する検証装置および車載用制御装置に関する。

近年、車載用の制御ソフトウェアにおいては、機械部品が電子化されるのに伴い、高度の動作信頼性が求められるようになってきている。この要求に従い、ソフトウェアの機能要求レベルの精度や、設計レベルでの設計方式の厳密化が求められていることは言うまでもない。

特に問題となるのは、制御アルゴリズム上の状態遷移の設計であり、システムが発生するイベントに則して、柔軟に外部事象に対応する設計でなければならない。これが、車載用の機能部材の制御を電子化する大きな利点であって、制御の高度化・精密化の要求に対応する主な原動力となっている。また、安全性の観点から、これら制御アルゴリズムの信頼性が大きく注目されており、電子的なハードウェアと制御ソフトウェアの力を借りて安全側に収束させる機能安全の分野に貢献できる。

上述したように、要求レベルや設計レベルの意図が正しく具現化されていることを検証し、確証を得ることが、車載部品の電子化の進展にともなって、今まで以上に重要となることが予測される。

これら車載用電子部品の設計の局面、特に組込型のマイクロコンピュータを動作させる制御ソフトウェアの作成に際しての活動を俯瞰してみると、システムの挙動に則した内部状態の定義と、状態間の遷移条件（イベント）およびその時の動作（アクション）に着目する、いわゆる状態遷移装置としての設計が行われるという特徴がある。

このような制御ソフトウェアの品質および信頼性を向上させるために、内部状態の定義と遷移条件を漏れなく書き下し、ソフトウェア作成につなげていくという手法が現状では一般的であり、内部状態と遷移条件の組が未規定もしくは想定外の場合は、自動的に例外処理等を挿入して制御ソフトウェアの安定性を向上させようとする状態遷移表ベースのソフトウェア自動生成技術がある（例えば、特許文献１）。

このようなソフトウェア自動生成技術の技術は、ソフトウェアの設計に際して、事前に漏れなく条件を洗い出し、考慮漏れをなくしてソフトウェアの頑健性（ロバストネス）を向上させようとする実稼働前の事前設計技術に属するものである。

特開２００６−１２０１７号公報

上述したように、マイクロコンピュータを動作させる車載用制御ソフトウェアの品質・信頼性を、いかに向上させるか、またその品質・信頼性が一定レベルを満たしていることを、いかに確証するかが、現状の切迫した課題となっている。

特許文献１で示す公知技術では、事前に状態遷移の定義の漏れ抜けをなくして制御ソフトウェアの品質・信頼性を向上しようとするものであるが、事前設計技術に属する技術ゆえに、実動作での検証を想定したものではない。また、いかに事前設計を厳密化しても、物理の神に委ねる実稼働状態での検証を経ないと、それのみでは、全体の品質・信頼性が確保できるものではない。

例えば、特定の内部状態から別の内部状態に遷移する遷移条件（イベント）に誤りを含んでいた場合、設計段階では満足しても、実稼働状態では作成した制御ソフトウェアの挙動は想定したものから異なったものになる。また、遷移先の内部状態を取り違えた場合にも、同様に実稼働状態での制御ソフトウェアの挙動は想定外のものとなる。

すなわち、事前に内部状態の定義と状態間の遷移条件（イベント）およびその時の動作（アクション）をいくら緻密に設計しても、実際には実稼動状態で挙動をモニタし検証しないと、制御ソフトウェアの品質と信頼性は判定できないことは常識となっている。

また、制御ソフトウェアの遷移条件（イベント）に対応する不具合、もしくは内部状態の遷移間違いは、システム全体としてのタイミングにまつわる稀少頻度の不具合を引き起こす。この稀少頻度の不具合とは、車両実稼働状態で１時間に１回、または１日に１回という現象も珍しくはない。

このようなタイミングにまつわる不具合は捕捉しづらいし、現象解析しづらいのが常である。従来の検証手法では、ロジックアナライザをマイクロコンピュータに接続し、ロジックアナライザのトリガ条件を工夫して現象解析（ソフトウェア不具合の内部要因分析）を行なっていた。

しかしながら、近年、ロジックアナライザと接続可能なバスが解放されているマイクロコンピュータの製品採用自体が車載用は、マイクロコンピュータのチップの微細化と動作周波数の増加等により、少なくなっている。

また、車載用マイクロコンピュータの機能を代替し、ロジックアナライザ等デバッグツールとバス接続可能な評価チップというものが存在するが、これらは実製品のマイクロコンピュータとの電気的機能等価性に問題があるものが多く、耐ノイズ性能が低いものが多い。したがって、実機検証にかけることができない。

加えて、現状のマイクロコンピュータは、制御ソフトウェアのアサーションベース検証に適さないという問題もある。

アサーションベース検証とは、設計のある属性（プロパティ）の成立を仮定し、チェックする検証手法で、これによりプロパティの仮定に反する条件（反証条件）を検出した場合、ソフトウェアの仕様または論理の欠陥と判断する検証技術のことである。

年々、制御ソフトウェアの規模が増加して、検証すべき項目が増加しつつあり、アサーションベース検証は、このようなテスト項目の爆発的増加に対して現実的でリーズナブルな検証手段を与えるという利点がある。

現状のマイクロコンピュータの構成では、アサーションベース検証を行なう場合、通常の制御ソフトウェアに、この機能をも含ませ、アサーション（表明）の逸脱を調べることになる。

すなわち、通常の制御ソフトウェアに、それを検証するための動作モニタソフトを併設することが必要になり、制御アルゴリズム以外のＣＰＵ処理時間の消費が多大なものになる。アサーション（表明）の逸脱を調べる動作モニタソフトは、単なるソフトウェアの検証用途のためだけであるので、このリソースの消費は、システム全体で見て割に合わない。

しかも、せっかく、このような動作モニタソフトを制御ソフトウェアに格納しても、該モニタの部分以外で、ソフトウェアの停止性が破綻した場合、例えば、無限ループに陥るなどした場合、正しく障害が検知できないという問題がある。

本発明は、前記解決しようとする課題に鑑みてなされたものであって、その目的とするところは、制御ソフトウェアの高度な検証技術、特にアサーションベース検証を提供するためになされたものであり、従来に比して検証効率を向上させた制御用マイクロコンピュータの検証装置および車載用制御装置を提供することにある。

前記目的を達成するために、本発明による制御用マイクロコンピュータの検証装置は、制御ソフトウェアを逐次実行するマイクロコンピュータとは別に、前記マイクロコンピュータと並行稼動可能に設置され、制御ソフトウェアの逐次実行によって前記マイクロコンピュータが実現すべき機能を検証する制御用マイクロコンピュータの検証装置であって、前記マイクロコンピュータが実現すべき機能に従って予め定める内部状態と、前記マイクロコンピュータの内部状態から他の内部状態への遷移条件を示す入力情報とを格納した時間順序表明手段を保有し、前記時間順序表明手段は、前記マイクロコンピュータの稼動に伴う実時間で並行して稼動して前記マイクロコンピュータの内部状態を推測し、当該内部状態が前記想定された状態遷移から逸脱したかを検出する。

本発明による制御用マイクロコンピュータの検証装置は、逸脱検出時には、警告発生のための出力処理を行う。警告発生のための出力処理としては、前記時間順序表明手段のハードウェアの出力を用いて外部に警告用信号を出力する処理、あるいは前記マイクロコンピュータに割込み信号を出力して異常検出を前記マイクロコンピュータに認識させる処理がある。

本発明による制御用マイクロコンピュータの検証装置は、好ましくは、前記時間順序表明手段は、マイクロプログラミング方式を用いた有限状態遷移機械にて構成するハードウェアとして、前記マイクロコンピュータとは別に設けられている。

本発明による制御用マイクロコンピュータの検証装置は、好ましくは、前記時間順序表明手段は、マイクロプログラミング方式の制御メモリを含み、前記内部状態と前記遷移条件を、前記制御ソフトウェアの動作状態の遷移を記述した状態遷移表より導出し、状態遷移のアサーション検証を行う。

本発明による制御用マイクロコンピュータの検証装置は、好ましくは、前記時間順序表明手段は、有限状態遷移機械にて構成するハードウェアの入力として、前記マイクロコンピュータの外部もしくは周辺デバイスより割込みコントローラに入力される割込イベント信号を並行して入力して状態遷移のアサーション検証を行う。

本発明による制御用マイクロコンピュータの検証装置は、好ましくは、前記時間順序表明手段は、有限状態遷移機械にて構成するハードウェアの入力として、前記マイクロコンピュータより割込みコントローラに帰還されるソフトウェアトラップ命令による割込み信号を入力し、前記マイクロコンピュータが逐次実行するソフトウェアとの同期処理を行う。

本発明による車載用制御装置は、上述の発明による制御用マイクロコンピュータの検証装置を備えて構成されている。

本発明による制御用マイクロコンピュータの検証装置によれば、検証すべきマイクロコンピュータ、制御ソフトウェアの負担を増加させることがなく、制御ソフトウェアもしくはシステム全体についてのアサーションベース検証機能を付加することができ、高い検証効率をもって検証を行うことができる。

図１は、本発明による制御用マイクロコンピュータの検証装置および検証対象の制御ソフトウェアを逐次実行するマイクロコンピュータの一つの実施形態を示している。

マイクロコンピュータ１０１は、検証対象の制御ソフトウェアを逐次実行する制御用マイクロコンピュータであり、制御ソフトウェアの解釈・実行を司るＣＰＵコア１０３、ＣＰＵコア１０３と内部バス１０６で接続された周辺デバイス１０４、割込みコントローラ１０５などを、必須の機能ブロックとして内蔵している。

例えば、周辺デバイス１０４としては、汎用タイマユニット、Ａ／Ｄ変換器、通信モジュール（何れも図示せず）などがあり、これらは、外部に対する入出力信号線１０７を通じて情報のやり取りを行う。

周辺デバイス１０４が取り扱う一連のイベント、例えば、タイマによるコンペアマッチやアウトプットコンペア、Ａ／Ｄ変換終了、通信フレームの送受信完了などのタイミング情報１０８は、割込みコントローラ１０５に伝えられる。

それとは別に、割込みコントローラ１０５には、マイクロコンピュータ１０１に外部より信号レベルの変化に応じて伝えられるＩＲＱ割込み信号１０９、ＣＰＵコア１０３自身が、制御ソフトウェアの指令を受けて発生するソフトウェアトラップ命令割込み信号１１０、及び後述する本発明に係る検証装置１０２が発生する警告割込み信号１２０が並行して入力される。

割込みコントローラ１０５は、制御ソフトウェアでイベントとして使用しない割込みをマスクした後、予めハードウェアで確定されるか、制御ソフトウェアで事前に設定された優先順位に基づいて割込み信号１１１をＣＰＵコア１０３に送出する。これにより、制御ソフトウェアは、該当する割込み処理への分岐を行う。

ここで注意すべきは、割込み信号１１１は、マイクロコンピュータ１０１に入力される全ての割込み情報を網羅しているものではなく、制御ソフトウェアの都合により割込みコントローラ１０５によって恣意的に取捨選択した信号であることである。

検証装置１０２は、検証すべき制御ソフトウェアを逐次実行するマイクロコンピュータ１０１と並行動作するマイクロプログラム内蔵方式の有限状態遷移ハードウェアによって構成されている。

検証装置１０２は、マイクロコンピュータ１０１と並行稼動可能であればよく、マイクロコンピュータ１０１のパッケージに物理的に同梱されていてもよいし、同一基板上に別体として配置し、電気的に結線されてもよい。

但し、マイクロコンピュータ１０１と独立して並行動作を行う性質上、各々の故障が相手に波及しないように、マイクロコンピュータ１０１と検証装置１０２とは、相互に電気的もしくは機能的に独立していることが望ましい。

検証装置１０２は、アサーションベース検証を行う検証装置であり、時間順序表明手段の主要なデバイスとして、マイクロプログラミング方式の制御メモリ１１３を有する。

制御メモリ１１３は、アサーションベース検証のためのファームウェアを組み込まれており、マイクロコンピュータ１０１や当該マイクロコンピュータ１０１の観測情報を通じて把握されるシステム全体の挙動として、検証すべきアサーション情報（検証内容）を格納する。換言すると、制御メモリ１１３は、マイクロコンピュータ１０１が実現すべき機能に従って予め定める内部状態と、一つの内部状態から他の内部状態への遷移条件を示す入力情報とを格納している。つまり、制御メモリ１１３には、アサーションベース検証のための状態遷移のアサーション情報（タイミング・アサーション情報）が予め定義されている。

制御メモリ１１３に格納する内部状態と遷移条件は、制御ソフトウェアの動作状態の遷移を記述した状態遷移表より導出することができる。

制御メモリ１１３の内容は、検証の実行に先立ってマイクロコンピュータ１０１がデータとして保持している内容を接続バス１１５を通じて設定してよいし、図１に示されている機能ブロックの全てとは無関係に、書き込みポート１１４を通じて設定されてもよい。

制御メモリ１１３の内容（１ステップの記憶内容）は、検証装置１０２の動作に伴い逐次的に読み出され、マイクロ命令レジスタ１１６と制御メモリアドレスレジスタ１１７に分割して入力される。

制御メモリアドレスレジスタ１１７の内容と、割込みコントローラ１０５の直前で分岐された割込みイベント（タイミング情報１０８、ＩＲＱ割込み信号１０９、ソフトウェアトラップ命令割込み信号１１０）のモニタ信号１１２の内容は、組み合せ論理回路１１９で論理合成されて帰還を取られ、制御メモリ１１３の新たな読み出しアドレスとなる。この動作を繰り返すことにより、検証装置１０２の動作が進展する。

このようにして、検証装置１０２は、制御メモリ１１３に予め定義されていたアサーション検証のための状態遷移を、割込みイベントのモニタ信号１１２をトリガとして進展し、異常な状態遷移イベントの発生を待ちつづけることになる。

したがって、検証装置１０２は、割込みイベントのモニタ信号１１２を遷移条件とするマイクロプログラミング方式の有限状態遷移機械（シーケンサ）の一種であると云える。しかも、検証装置１０２は、マイクロコンピュータ１０１の動作自体と独立して並行動作を行うものとなる。

検証装置１０２は、マイクロコンピュータ１０１より割込みイベントのモニタ信号１１２を入力し、マイクロコンピュータ１０１の稼動に伴う実時間で並行して稼動してマイクロコンピュータ１０１の内部状態を推測し、当該内部状態が予め格納した状態遷移から逸脱したかを検出する。

見方を変えれば、検証装置１０２は、マイクロコンピュータ１０１が実行の制御ソフトウェアの内部状態、もしくは、マイクロコンピュータ１０１から観測できるシステムの全体の内部状態を、内蔵する制御メモリ１１３に格納されたアサーション情報を参照して推測しつつ、異常な状態が発生しないかを、モニタする監視装置であると換言できる。

検証装置１０２は、異常な状態遷移を検出した場合には、マイクロ命令レジスタ１１６の内容を変化させることによって、言い換えれば、その内容の転送元である制御メモリ１１３の内容を変化させることによって、警告信号を外部に送出する出力処理を行う。

この警告発生のための出力処理には、２種類あり、一つは外部に対して警告信号１２１を送出する処理である。これは、外付用のモニタツール、警告ランプ、もしくはデバッグ用のログ採集ツールの利用を念頭においている。もう一つは、割込みコントローラ１０５に帰還して入力される警告割込み信号１２０を出力する処理である。この仕組みによって、マイクロコンピュータ１０１の制御ソフトウェア自体が、検証装置１０２を介して異常を発生したことを認識できる。マイクロコンピュータ１０１は、警告割込み信号１２０の入力を適当なストレージにログ情報として保有することもできる。

図２は、本発明による検証装置１０２が検証すべきエンジン（内燃機関）システムの一例を示している。図２では、一つの気筒分しか図示していないが、４気筒４サイクルエンジンの燃料・点火を司るエンジン制御用ＥＣＵ（Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）２０１に応用した例を示している。本発明による検証装置１０２は、マイクロコンピュータ１０１と共に、制御用ＥＣＵ２０１に実装される。

エンジン制御用ＥＣＵ２０１の入力としては、クランク角度の情報を得るためにクランク軸１８０度毎にクランク信号を発生するクランク角センサ２０２、それより角度分解能の小さいリングギアセンサ２０３が出力するセンサ信号がある。その他、エンジン空気量を推定するための吸気管圧力センサ２０５、空燃比をモニタするためのＯ_２センサ２０８などが出力するセンサ信号がある。

一方、エンジン制御用ＥＣＵ２０１の出力としては、吸入空気量を制御するためのスロットル・アクチュエータ２０４、ガソリン燃料噴射を行うためのインジェクタ２０６、気筒内混合気に点火するための点火イグナイタ２０７などの制御信号がある。

図３は、４気筒エンジンのクランク信号（ＲＥＦ）３０２と、４サイクルエンジンを構成する各気筒の燃焼サイクル３０１、及び点火信号（Ｉｇｎ．）３０３の対応をタイミングチャートに表したものである。

ここにおいて、アサーションベース検証を行う対象として、クランク信号（ＲＥＦ）３０２と点火信号（Ｉｇｎ．）３０３とのタイミング関係の健全性を検証することを目的とし、それに対応する検証装置１０２の実施形態を説明する。

点火信号（Ｉｇｎ．）３０３は、図３より明らかなように、クランク信号（ＲＥＦ）３０２と次のクランク信号の間（クランク軸角度では１８０度毎）に、確実に１回の点火を行うことを要求されている。

実際には、点火信号は所定の気筒に正しく振り分けなければならないが、この振り分け機能の健全性は、今回の検証の対象外とする。したがって、図中、３０３で示すように、気筒振り分け前の点火の基準信号を生成するタイマデバイスの健全性を検証することになる。

ちなみに、点火信号（Ｉｇｎ．）３０３の信号レベル“Ｈｉｇｈ”の期間は、点火イグナイタ２０７の内蔵コイルに点火用の電流エネルギーを蓄積している期間であって、実際の点火は、この波形の“Ｈｉｇｈ”から“Ｌｏｗ”の切り替わりで発生する（図３の燃焼サイクル３０１中に☆印で示す。）。
このように規定された点火状態が、図２で示すようなエンジンシステムで失われることは、商品性の観点から致命的なことであって、運転者にはエンジン発生トルクのばらつきとして認識されるばかりではなく、排気ガス性能にも大きな悪影響を及ぼす。

実際に、このような点火系の制御ソフトウェアを作成している局面を考えると、初期には正常であった制御が、種々の補正仕様を入れ込む時に本来の機能が失われてデグレードが生じ、欠陥が見過ごされたまま製品化に至る場合がありうる。加えて、通常状態では捕捉されないが、制御ソフトウェアの特定の条件下でのタイマデバイスの規定外の操作や、割込み信号処理の競合による処理遅れの累積、もしくはソフトウェアの暴走などで、このような現象が発生する可能性もある。

このような不具合現象の捕捉は、現象が稀少頻度であるために捉え難いものであって、制御ソフトウェアのデバッグに多大な時間を要する原因となる。また、どれほどまでの検証延べ時間を考慮し、不具合事象が発生しなかったときに、システムが健全であるという判断または確証を得られるのか、という理論も現状では存在していない。

こういう時に威力を発揮するのが、本発明によるアサーションベース方式の検証装置１０２であり、検証装置１０２は、不具合現象を防止するための事前・事後の備えばかりではなく、システムの稼働と並行して稼働し、健全性を、オンラインで、リアルタイムに常時モニタすることを可能とするものである。

実際に、アサーションベース検証を検証装置１０２に落し込む一実施形態を、タイミングチャート（図４）と、状態遷移図（図５）と、状態遷移表（図６）の各々を対比した形で説明する。

図４は、クランク信号（ＲＥＦ）３０２と点火信号（Ｉｇｎ．）３０３の波形をタイミングチャートとして表したものである。

クランク信号（ＲＥＦ）３０２の間隔は、エンジン回転数によって変化する。すなわち、エンジン回転数が低いときは、クランク信号（ＲＥＦ）と次のクランク信号（ＲＥＦ）の間隔は広く、エンジン回転数が増加するに従って間隔が狭くなる。

これに対し、点火信号（Ｉｇｎ．）３０３の信号レベルの“Ｈｉｇｈ”期間は、点火イグナイタ２０７に蓄積すべき電流エネルギーによって決まり、エンジン回転数とは独立である。

したがって、エンジン回転数が低回転の時には、図４に符号４０１により示されているように、点火信号（Ｉｇｎ．）“Ｈｉｇｈ”期間は、隣り合うクランク信号（ＲＥＦ）間に収まる。これに対し、エンジン回転数が高回転の時には、図４に符号４０２により示されているように、点火信号（Ｉｇｎ．）“Ｈｉｇｈ”期間は、クランク信号（ＲＥＦ）を跨ぐことになる。

何れにせよ、点火信号（Ｉｇｎ．）３０３の“Ｈｉｇｈ”から“Ｌｏｗ”の切り替わりは、隣り合うクランク信号（ＲＥＦ）間に厳密に１箇所発生（エンジンの点火ポイント）し、これがあるべき姿である。

点火信号（Ｉｇｎ．）３０３の“Ｈｉｇｈ”から“Ｌｏｗ”のタイミング、および“Ｌｏｗ”から“Ｈｉｇｈ”のタイミングは、何れも周辺デバイス１０４のなかの汎用タイマのコンペアマッチ機能により発生しており、割込み信号の発生要因となる。これをアウトプットコンペアＯＣと略記する。

一方、クランク信号（ＲＥＦ）３０２の間隔は、エンジン回転数計測のために、汎用タイマのインプットキャプチャ機能により計測されており、同じく割込み信号の発生要因となる。これをインプットキャプチャＩＣと略記する。

ここで、クランク信号（ＲＥＦ）３０２と点火信号（Ｉｇｎ．）３０３の時間的位置関係に着目し、有限遷移装置の状態を定義する。

定義する各状態は、図４に、符号Ｓ１〜Ｓ４により示されている。ここでは、クランク信号（ＲＥＦ）３０２到来前で、点火信号（Ｉｇｎ．）３０３が“Ｌｏｗ”の時間を状態Ｓ１、クランク信号（ＲＥＦ）３０２到来以後で、点火信号（Ｉｇｎ．）３０３が“Ｌｏｗ”の時間を状態Ｓ２と定義する。一方、クランク信号（ＲＥＦ）３０２到来前で、点火信号（Ｉｇｎ．）３０３の“Ｈｉｇｈ”の時間を状態Ｓ４、クランク信号（ＲＥＦ）３０２到来以後で、点火信号（Ｉｇｎ．）３０３が“Ｈｉｇｈ”の時間を状態Ｓ３と定義する。

状態Ｓ３への移行をもって、クランク信号（ＲＥＦ）の履歴は、「到来前と解釈する」と定義すれば、状態Ｓ３に引き続く状態は、状態Ｓ１となる。この状態Ｓ３から状態Ｓ１に遷移するタイミングが、点火タイミングとなる。

前述したアウトプットコンペアＯＣおよびインプットキャプチャＩＣを、遷移条件のイベントとして、上述した各状態の状態遷移図を記述したものを図５に示す。

図５において、丸で囲った記号は、図４に対応する“状態”を示している。“状態”と他の“状態”は矢印で結ばれており、矢印の方向が状態遷移の方向を示している。また、矢印の脇に示す英字（すなわちＩＣとＯＣ）が状態遷移のトリガとなる遷移条件を示している。なお、図５で、状態Ｓ０は、検証装置１０２が初期状態であり、アサーションベース検証に入る前の待機状態にあることを示している。

図４のエンジン低回転時４０１およびエンジン高回転時４０２の点火信号（Ｉｇｎ．）波形と対応付けると、
エンジン低回転時：Ｓ１→Ｓ２→Ｓ３→Ｓ１の繰り返し
エンジン高回転時：Ｓ１→Ｓ４→Ｓ３→Ｓ１の繰り返し
となる。

以上述べた状態遷移を、状態遷移表に対応付けたものが図６である。この表の表現方法として、行方向を各状態の種別（６０１）に対応付け、列方向を遷移イベントの種類（６０２）に対応付けしている。特定の“状態”のときに特定の“イベント”が入力されたときの状態遷移は、状態に対応する列とイベントに対応する行の交点のセルを見れば判断できる。

例えば、状態Ｓ１のときにイベントＯＣが入ったときの状態遷移は、セル６０３を見ればよい。セル６０３には、上段に“４”下段に“通電開始”と記されている。ここで、上段の“４”は次に遷移すべき“状態”すなわちＳ４を示している。下段は、一般的には、遷移時に実行すべき処理を記述するが、本実施形態の検証装置１０２は、マイクロコンピュータ１０１に内蔵される制御ソフトウェア（もしくはシステム全体の機能要求）の内部状態遷移を推定し、挙動をモニタするだけであるので、ここでは、状態遷移のシステム全体としての意味を示してある。

×印のついているセルは、有り得ない状態とイベントの組合せを示し、例えこのようなイベントが発生しても何も状態遷移を引き起こさないことを示している。これは、現状の同一状態に再び遷移すると考えてもよい。

ここで、Ｓ０の列は、図５で示す状態Ｓ０に対応しており、ソフトウェアトラップ命令（図６の６０２中、イベントでＴＲと図示）をマイクロコンピュータ側で発行して初めてＳ１の列に遷移しアサーション検証が始まることを示している。

セル６０４は、状態Ｓ２の時にイベントＩＣが発生したことを示している。すなわち、クランク信号（ＲＥＦ）の間に、点火信号（Ｉｇｎ．）の“Ｌｏｗ”から“Ｈｉｇｈ”への立上げが発生しなかったということであり、これは明らかに失火エラーである。このような異常遷移を検出した場合には、検証装置１０２は、前述した警告信号を発生し、状態自体はＳ０に遷移して検証を停止する。

このように警告信号を発すべき異常遷移は、図６では、セルにハッチングをかけて示してある。

同様に、セル６０５は、点火信号（Ｉｇｎ．）“Ｈｉｇｈ”期間中に、次のクランク信号（ＲＥＦ）のイベントＩＣが到来した場合であり、点火タイミングが遅延したための失火エラーと解釈できる。

セル６０６は、クランク信号（ＲＥＦ）で既に一回の点火を経験した後、次のクランク信号（ＲＥＦ）の期間に入る前にもう一度点火が発生することを示す。したがって、これは、誤点火エラーと解釈できる。

このように、検証装置１０２は、状態遷移をトレースし、図５で示す通常の状態遷移より経路が外れることを認識することによって、異常状態を検出することができる。

図７は、本検証装置１０２の遷移条件（イベント）を、どこから採集するかを示した図である。

周辺デバイス１０４で発生する重要なイベントは、全て個別に割込み要因７０１という形で割込みコントローラ１０５に伝えられる。

但し、割込みコントローラ１０５は、ＣＰＵコア１０３の制御下にある。なぜならば、割込み要因のうち何を使用するかの選択と、受け付けられた割込みのうち何を優先するかの優先度の設定は、ＣＰＵコア１０３を通じて制御ソフトウェアにより設定できるからである。

すなわち、割込み要因７０１は、割込みコントローラ１０５を通ることによって、マスク化と優先順位付けの処理が施された割込み信号７０３となり、逐次的にＣＰＵコア１０３に伝えられる。

検証装置１０２としては、全ての割込み要因の情報を、制御ソフトウェアの外乱を受けることなく入手したい要請があることは前述した通りである。

また、優先順位も本発明の機能に関しては余分な修飾となる。図６を見て分かるように、検証装置１０２の状態遷移は、イベントの発生順序に従い忠実に遷移を行う必要がある。そして、それらの処理時間も、ＣＰＵコア１０３側で実行する制御ソフトウェアに比して無視できるくらいに小さい。ゆえに、割込みの処理優先度を考慮する必要はない。

したがって、以上の状況を考慮し、検証装置１０２の遷移条件（イベント）７０２としては、割込みコントローラ１０５を通る前の生の割込み要因７０１を分岐させて取り込むことが必須の構成となる。

図８は、図６の状態遷移表を実行可能なソフトウェアに変換したものであり、ここではＣ言語の文法に基づいて記述してある。実際には、このようなソフトウェアをファームウェア・コンパイラなどを通すことによってデータ列に変換し、検証装置１０２の制御メモリ１１３に格納する。

プログラムブロック８０１は、図６の状態遷移表を忠実に構造体２次元テーブルに書き直したものであり、２次元テーブルの列はその時の状態“ｓｔａｔｕｓ”によって、行は遷移イベントの種類“ｅｖｅｎｔ”によって検索される。

上記２次元テーブルの一要素は、数字と関数名の組で表されている。一例として、図６のセル６０３に対応する配列要素“｛４，ｎｏｐ｝”は、次に遷移する状態が、配列添え字“４”で表される状態Ｓ４であり、その遷移時に呼び出される関数の関数ポインタの値が“ｎｏｐ”であることを示す。

実際に状態遷移トレースを行う実行部をプログラムブロック８０２に示す。実行の流れは、図９のフローチャートに基づき後述する。

プログラムブロック８０３は、通常遷移時に呼び出される関数ブロックである。同様にプログラムブロック８０４は、異常遷移時に呼び出される関数ブロックを示す。これら両ブロックの機能の詳細は、同じく図９のフローチャートに基づき後述する。

図９は、図８の主たる動作を司るプログラムブロック８０２、８０３、８０４を、フローチャートとして示している。

開始点９００は、検証装置１０２のハードウェアリセット解除後に動作が位置する場所であり、引き続き処理９０１で、状態変数“ｓｔａｔｕｓ”を初期化する。これにより、検証装置１０２は、図５で示す状態Ｓ０に位置することとなる。

処理は、引き続いて無条件に無限ループ処理９０２〜９０７に入ることになる。

処理９０２では、外部のイベントの発生を、イベント待ち関数“ＷａｉｔＥｖｅｎｔ（）”にて待つ。この“ＷａｉｔＥｖｅｎｔ（）”関数は、イベントが発生するまで、この関数の中で待機し、イベントが発生したならば、イベントの種類を戻り値として返すものと仮定する。この属性を明確にするため、図９では、判定９０３でイベントが発生するまで処理９０２の頭に帰るループを便宜上表記してある。

イベント発生後は、処理９０４に移行し、現在の状態番号とイベントの番号より、前述の２次元テーブル８０１を検索し、次に遷移すべき状態番号を変数“ｎｅｘｔｓｔａｔｕｓ”に確保する。

引き続く処理９０５では、同じく現在の状態番号とイベントの番号より、前述のプログラムブロック８０１の２次元テーブルを検索し、実行すべき関数の関数ポインタの値を変数“ｃａｌｌｐ”に確保する。

次の処理９０６では、上記関数ポインタを利用して実際の関数をコールする。前述したように、プログラムブロック８０１の２次元テーブルの定義により、正常遷移の場合には、処理９０８〜９１０の“ｎｏｐ関数”がコールされ、本実施形態の場合では、何の処理も行われない。

異常遷移の場合には、処理９１１〜９１３の“ｅｒｒ関数”がコールされる。この“ｅｒｒ関数”の機能として、外部に警告信号を発行したり（図１の警告信号１２１）、マイクロコンピュータに警告割込み信号を送出したり（図１の警告割込み信号１２０）する手段を取り得ることは、前述した通りである。

引き続く処理９０７では、処理９０４で求めた新たな状態番号により、現在の状態を表す状態変数“ｓｔａｔｕｓ”の内容を書き換え、状態変数を更新する。

この後、処理９０２に制御を戻し、電源が切られるまで、無限ループ処理９０２〜９０７を永久に実行する。

以上述べた処理手続きは、検証装置１０２の制御メモリ１１３に格納されたファームウェアの機能であるが、以下の図１０、１１にフローチャートとして示す同期処理、異常警告処理は、マイクロコンピュータ１０１側の制御ソフトウェアの機能である。

検証装置１０２とマイクロコンピュータ１０１は、独立に並行動作を行うので、動作の初めにおいて、互いの状態認識を合わせる同期処理が必要になる。また、検証装置１０２が異常を検出した後は、動作を停止する（すなわち状態Ｓ０に戻る）ので、引き続き検証装置１０２の再起動を行うためにも上記の同期処理が必要になる。

図１０の開始点１０００は、マイクロコンピュータ１０１側の制御ソフトウェアの起動開始点であり、ハードウェアリセット解除後に、ここに位置する。

引き続く処理１００１では、本実施形態で開示した点火制御をも含めたエンジン制御全般の初期化処理を行い、その後、判定１００２に移行する。

判定１００２では、システム全体が、図４および図５で云う状態Ｓ１に位置するかどうかの判定を行う。もし、位置しなければ、待機動作を行う。

状態Ｓ１は、もともとエンジン停止時の状態であるので、起動直後は、状態Ｓ１であることは自明であるが、何らかの処理遅れや電源ＯＮかつ即始動の状況に対抗して検証装置１０２との同期を確実なものとするため、この判定が実行される。

システムが状態Ｓ１に位置する確信を得た後、引き続く処理１００３で、検証装置１０２にソフトウェアトラップ割込みを送出する。この動作により検証装置１０２の状態が前述したようにＳ１に移行し、マイクロコンピュータ１０１と検証装置１０２の同期が取れたことになる。

図１１は、前述したように検証装置１０２が異常遷移を検出し、マイクロコンピュータ１０１に警告割込みを送出した後に、マイクロコンピュータ１０１が実行する異常警告割込み処理ルーチンを示すフローチャートである。

割込み処理のエントリ１１００より処理が始まり、処理１１０１では、異常の状況として、その時点の制御ソフトウェアの重要な変数、例えば、エンジン回転数、吸入空気量のスナップショットを、その時点のタイムスタンプとともに不揮発性メモリ（図示せず）に記憶する。

引き続く処理１１０２では、運転者が異常を認識可能なように、外部に対して警告信号（ランプ点灯等）の出力処理を行う。ここで行う警告信号の出力は、マイクロコンピュータ１０１側の処理であるので、図１の警告信号１２１のような検証装置１０２自体の出力とは異なり、例えば、図１の周辺デバイス１０４の一種であるデジタル出力ポートを用いた出力（図１の入力出力信号１０７）となる。

引き続く判定１１０３と処理１１０４を併せたブロック１１０６は、図１０のブロック１００２とブロック１００３を併せたブロック１００５と同じものであり、異常を報告して停止した検証装置１０２に再び再起動をかけるために必要な同期処理である。

同期処理としての意味や機能の解説は、図１０の解説で述べた事項と同じである。

以下に、本発明による制御用マイクロコンピュータの検証装置の好ましい実施形態、効果を列記する。
（１）アサーションベースの検証を行う検証装置１０２はマイクロコンピュータ１０１とはまったく異なる独立したハードウェアであり、制御ソフトウェア自身のＣＰＵ時間を消費することはない。従って、制御ソフトウェアは、検証装置１０２の存在を意識することなく与えられたリソースによる最高のパフォーマンスで動作することができる。
また、マイクロコンピュータ１０１と検証装置１０２のハードウェアが独立したものであり、マイクロコンピュータ１０１および検証装置が並行して動作しているので、マイクロコンピュータ１０１で動作している制御ソフトウェアの停止性が破綻しても、検証装置１０２の検証機能が損なわれることがない。

（２）検証装置１０２をマイクロプログラミング方式を用いた有限状態遷移機械にて実現することにより、内蔵する制御メモリを書き換えれば、種々の検証項目に対応することができる。マイクロプログラミング方式自体が、周知で枯れた技術であるから、低価格でハードウェアを作成可能である。例えば、マイクロコンピュータ自体はもとより、周辺デバイスの汎用タイマ・通信モジュール等のシーケンサに、この技術が使われている。

（３）検証装置１０２は、検証すべき制御ソフトウェアを逐次実行するマイクロコンピュータと並行動作するマイクロプログラム内蔵方式の有限状態遷移ハードウェアによって、簡便にアサーションベース検証を実行することができる。しかも、このハードウェアは、検証内容が制御メモリに置かれるので、書換え可能であり、システム全体の機能要求の検証から車載用制御ソフトウェアの品質の検証まで、広範囲の検証アイテムに対応できる。

（４）車載機器の制御ソフトウェアは状態遷移表に基づいて設計されることが多く、設計者にとって状態遷移表を記述することは経験者も多く容易なことであるから、マイクロプログラミング方式で使われる制御メモリの内容を、マイクロコンピュータ１０１の動作状態の遷移を記述した状態遷移表より導出することにより、検証装置１０２の作成効率が向上する。
また、非検証対象の制御ソフトウェアの余分な制御を引き剥がし簡略化して骨格（制御アルゴリズムのスケルトン）のみを取り出し、検証装置１０２の制御メモリ内容とすることができる。他方では、システム全体からのあるべき機能要求として、制御ソフトウェアとは独立に、アサーション内容を摘出してコンパイルし、検証装置１０２の制御メモリ内容とすることができる。すなわち、現状の制御ソフトウェアベースの下流からのアサーションと、システム機能要求をもとにした上流からのアサーションの２つのアサーション検証が可能となる。
なお、上述した実施形態の類型としては、前述したシステム機能要求をもとにした上流からのアサーション検証に該当する。

（５）車載用制御ソフトウェアでは、外部の事象変化（イベント）に基づき状態遷移を起こすものが多く、特に、外部もしくは周辺デバイスの割込み信号を状態遷移トリガとすることが特徴的である。従って、この割込み信号を検証装置１０２にも並行して入力することにより、制御ソフトウェアの状態遷移を外部より正しく推測することができる。
但し、マイクロコンピュータ１０１においては、割込みコントローラ１０５にてこの割込み信号をマスクすることができるので、割込みコントローラ以後の信号を検証装置１０２に導くことは、制御ソフトウェアにより検証装置１０２の入力を制限できることになり、好ましくない。また、制御ソフトウェアにとって状態遷移トリガに使用しない割込み（すなわち割込みマスクによって割込み処理を設定しない割込み）であっても、周辺デバイスやシステム全体にとって重要な割込み信号であることがある。
したがって、割込み要因の要不要を独自に検証装置１０２側で設定できるように、割込みコントローラを経由しない割込み信号を入力とすることが好ましい。

これは、上述のシステム機能要求をもとにした上流からのアサーションを行う場合に特に必要となる。これらのことにより、検証装置１０２の入力は割込みコントローラに入るすべての割込み信号をモニタして検証装置１０２自体の状態遷移トリガとできることが望ましい。

（６）検証装置１０２には、モニタすべきマクロコンピュータ１０１および制御ソフトウェアの正常な状態遷移と異常な状態遷移のパターンが格納されている。
これは、むしろ、正常な状態遷移パターンが格納されており、それから逸脱する状態遷移パターンは全て異常と判定してよいことを示している。検証装置１０２は、モニタすべきマクロコンピュータコア１０１および制御ソフトウェアの状態遷移の内部状態を常時推測している。これは、すなわち、マクロコンピュータ１０１および制御ソフトウェアの内部状態と、検証装置１０２のマイクロプログラミングによる内部状態が常時同期していると考えてよい。
この点において、検証装置１０２のマイクロプログラミングによる内部状態および状態遷移は、制御ソフトウェアの骨格的な状態遷移のパターン（もしくは、上流からのシステム要求から由来した状態遷移のパターン）を抜きだしてイベントと状態の組としたアサーション（表明）となっている。
したがって、この表明から逸脱するマクロコンピュータ１０１および制御ソフトウェアの振る舞いは、イベントの時系列的な予測値が検証装置１０２に予め設定したパターンと食い違うという現象として現れる。
検証装置１０２は、それを検出することによりイベントのタイミングが異常であることを判定し、外部に警告用信号を出力する。これは、車載用制御装置外のモニタリングツールに対してでもよいし、機能安全用として外部に設けられた保護装置、もしくはバックアップ装置、もしくは車両の運転者に対する警告ランプのようなものでもよい。
加えて、モニタすべきマイクロコンピュータコア自体に異常検知時に割込み信号を帰還させることにより、マイクロコンピュータコア自身で異常が発生したことを判断可能となり、自己診断に有用な機能を付加することとなる。

（７）制御ソフトウェアの状態遷移トリガ（イベント）として割込み信号のみで全て充足できることではないことは制御ソフトウェアを作成する立場からは自明のことである。
例えば、Ａ／Ｄ変換の値の変化、もしくはＤＩ／ＤＯ（デジタルインプット／デジタルアウトプット）の信号の変化も、制御ソフトウェアにとって状態遷移のトリガとなり得る。これを正しく検証装置１０２に伝え、制御ソフトウェアと検証装置の内部状態の同期を取るために、前記ソフトウェアトラップ割込みを使用する。
このソフトウェアトラップ割込みは、制御ソフトウェアの状態遷移時にコールされる。この割込みは、検証装置１０２に状態遷移トリガを伝えるためだけであるので、制御ソフトウェアとしてはこの割込みで処理すべき操作はない。
従って、リソース（例えばＣＰＵ時間）の消費は最小で、制御プログラムと該検証装置の内部状態の同期を行うことができる。

（８）検証装置１０２とマイクロコンピュータ１０１を同時に車載用制御装置の中に組み入れて製品化することができる。昨今、車載用制御装置の機能は高度化し、一部は従来からのメカニカル部品に取って代わろうとしていることは前述した通りである。
一例を挙げれば、電動パワーステアリング（ＥＰＳ：Ｅｌｅｃｔｒｏｎｉｃ Ｐｏｗｅｒ Ｓｔｅｅｒｉｎｇ）や電動ブレーキ（Ｂｒａｋｅ ｂｙ Ｗｉｒｅ）などがあげられる。
このような安全に関わる機能部品を電子化する場合、機能安全としての種々な保護回路・診断回路・バックアップ回路が要求され、このような用途に対しても、本発明による検証装置１０２は、製品組み込み用のオンボード異常監視装置として用いることができる。

本発明による制御用マイクロコンピュータの検証装置およびマイクロコンピュータの一つの実施形態を示す機能ブロック図。 検証対象のシステムの全体図。 ４気筒４サイクルエンジンの燃焼サイクルと点火タイミングを示すタイミングチャート。 ４気筒４サイクルエンジンのクランク信号と点火信号と状態分けの対応を示したタイミングチャート。 点火の各状態における遷移条件（イベント）と遷移の対応を示した状態遷移図。 点火の各状態における遷移条件（イベント）と遷移の対応を示した状態遷移を表形式で示す状態遷移表。 割込み処理と状態遷移の遷移条件（イベント）の取り出し位置を示す機能ブロック図。 本実施形態の検証装置のファームウェアをＣ言語で記述したプログラムソースリスト。 本実施形態の検証装置の動作を示すフローチャート。 マイクロコンピュータ側の制御ソフトウェアの検証装置起動ルーチンを示すフローチャート。 マイクロコンピュータ側の制御ソフトウェアの異常警告割込み処理ルーチンを示すフローチャート。

符号の説明

１０１ マイクロコンピュータ
１０２ 検証装置
１０３ ＣＰＵコア
１０４ 周辺デバイス
１０５ 割込みコントローラ
１１２ 割込みイベントのモニタ信号
１１３ 制御メモリ
１２０ 警告割込み信号
１２１ 警告信号
２０１ エンジン制御用ＥＣＵ
２０２ クランク角センサ
２０７ 点火イグナイタ

Claims (7)

1. 制御ソフトウェアを逐次実行するマイクロコンピュータとは別に、前記マイクロコンピュータと並行稼動可能に設置され、制御ソフトウェアの逐次実行によって前記マイクロコンピュータが実現すべき機能を検証する制御用マイクロコンピュータの検証装置であって、
   前記マイクロコンピュータが実現すべき機能に従って予め定める内部状態と、前記マイクロコンピュータの内部状態から他の内部状態への遷移条件を示す入力情報とを格納した時間順序表明手段を保有し、
   前記時間順序表明手段は、前記マイクロコンピュータの稼動に伴う実時間で並行して稼動して前記マイクロコンピュータの内部状態を推測し、当該内部状態が前記遷移条件から逸脱したかを検出し、逸脱検出時には、警告発生のための出力処理を行うことを特徴とする制御用マイクロコンピュータの検証装置。
2. 前記警告発生のための出力処理として、前記時間順序表明手段のハードウェアの出力を用いて外部に警告用信号を出力するか、前記マイクロコンピュータに割込み信号を出力して異常検出を前記マイクロコンピュータに認識させる処理を行うことを特徴とする請求項１に記載の制御用マイクロコンピュータの検証装置。
3. 前記時間順序表明手段は、マイクロプログラミング方式を用いた有限状態遷移機械にて構成するハードウェアとして、前記マイクロコンピュータとは別に設けられていることを特徴とする請求項１または２に記載の制御用マイクロコンピュータの検証装置。
4. 前記時間順序表明手段は、マイクロプログラミング方式の制御メモリを含み、前記内部状態と前記遷移条件を、前記制御ソフトウェアの動作状態の遷移を記述した状態遷移表より導出し、状態遷移のアサーション検証を行うことを特徴とする請求項１から３の何れか一項に記載の制御用マイクロコンピュータの検証装置。
5. 前記時間順序表明手段は、有限状態遷移機械にて構成するハードウェアの入力として、前記マイクロコンピュータの外部もしくは周辺デバイスより割込みコントローラに入力される割込イベント信号を並行して入力して状態遷移のアサーション検証を行うことを特徴とする請求項１から４の何れか一項に記載の制御用マイクロコンピュータの検証装置。
6. 前記時間順序表明手段は、有限状態遷移機械にて構成するハードウェアの入力として、前記マイクロコンピュータより割込みコントローラに帰還されるソフトウェアトラップ命令による割込み信号を入力し、前記マイクロコンピュータが逐次実行するソフトウェアとの同期処理を行うことを特徴とする請求項１から５の何れか一項に記載の制御用マイクロコンピュータの検証装置。
7. 請求項１から６の何れか一項に記載の制御用マイクロコンピュータの検証装置を備えて構成されることを特徴とする車載用制御装置。

Images