自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置
【課題】実行されるプログラムが要求仕様に従っているか効率よく監視を行うことができる、自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置を提供する。
【解決手段】センサやスイッチ等の外部機器から情報を取得する手段と、プログラムが実行される演算処理装置と、を有し、前記情報取得手段が取得した情報をもとに演算を行う演算プログラムと、仕様記述言語で記述された形式仕様記述から生成した監視プログラムと、が、前記演算処理装置上で実行され、前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理が、要求仕様の定義に従っているか否かを検証する。前記監視プログラムおよび演算プログラムは、コード書込み手段を有するソフトウェア作成装置によってコンピュータに書き込むことができる。
【解決手段】センサやスイッチ等の外部機器から情報を取得する手段と、プログラムが実行される演算処理装置と、を有し、前記情報取得手段が取得した情報をもとに演算を行う演算プログラムと、仕様記述言語で記述された形式仕様記述から生成した監視プログラムと、が、前記演算処理装置上で実行され、前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理が、要求仕様の定義に従っているか否かを検証する。前記監視プログラムおよび演算プログラムは、コード書込み手段を有するソフトウェア作成装置によってコンピュータに書き込むことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置に関する。
【背景技術】
【０００２】
近年、自動車に搭載されているエレクトリックコントロールユニット（ＥＣＵ）のように、組み込みシステムを用いたコンピュータを車両に搭載することによって、ソフトウェアにて車両の状態を制御することが一般的になっている。
【０００３】
これらの車載コンピュータにおいては、制御している各種装置の故障や、それによる予期せぬ動作に起因する事故を防止するため、自己診断機能が備えられている場合が多い。自動車の場合、自己診断機能は「ダイアグノーシス（diagnosis）」や「ＯＢＤ（On-board diagnostics）」と呼ばれている。自己診断機能は、車載コンピュータに、仕様に定義
されていない信号が入力された等の異常な状態を検知して、運転者に通知し、コンピュータの内部記憶装置に詳細情報を記録するといった機能を持っている。
【０００４】
自己診断機能を備えたコンピュータの開発においては、定められたソフトウェア仕様を元に開発者が自己診断プログラムを設計し、診断対象のプログラムとあわせて実装する方法が一般的である。自己診断は、たとえば試験用の擬似入力信号を発生させ、それに対応する出力が仕様に沿ったものであるかプログラム内で検証するといった方法で実施される。
【０００５】
これらの自己診断機能は、診断対象となるプログラムが持つ機能ごとに設計と実装を行わなければならないため、主にコストの問題により、車載コンピュータが有する全機能を対象とするのではなく、例えば安全に関係する部分など、あらかじめ定められた範囲のみをチェックすることが一般的である。特許文献１においては、車両を制御するコンピュータに接続し、故障診断に必要なデータのみを採取する故障診断装置が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−１６６３２８号公報
【非特許文献】
【０００７】
【非特許文献１】Efficient translation of LTL formulae into Buchi automata, Dimitra Giannakopoulou, RIACS Technical Report 01.29, June 2001
【非特許文献２】“Simulink Coder”、［online］、MathWorks, Inc.、［平成２３年４月１５日検索］、インターネット＜ URL ：http://www.mathworks.co.jp/products/simulink-coder/index.html＞
【非特許文献３】“Simulink HDL Coder”、［online］、MathWorks, Inc.、［平成２３年４月１５日検索］、インターネット＜ URL ：http://http://www.mathworks.com/products/slhdlcoder/index.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
前述の自己診断機能は、車載コンピュータに接続されたセンサが正常に動作していることや、車載コンピュータの処理が正常に行えていることを、専用に設計されたプログラム
が監視する。しかし、コストの問題により、車載コンピュータが有する全ての機能を監視することは一般的ではなく、監視できない機能が少なからず存在するという問題がある。また、設計段階で、自己診断機能のプログラム自体にバグが混入する恐れがあるため、従来技術では、車載コンピュータの完全な自己診断を行うことができないという問題がある。
【０００９】
本発明は上記の問題点を考慮してなされたものであり、実行されるプログラムが要求仕様に従っているか効率よく監視を行うことができる、自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置では、上記目的を以下の手段により実現する。
【００１１】
組込みソフトウェアの開発においては、モデルベース開発、および形式手法が用いられる場合がある。モデルベース開発とは、統一モデリング言語等のモデル記述言語によって、コンピュータ上にソフトウェアの仕様を表現した仮想的なモデル（ソフトウェアモデル）を作り、モデルを検証しながら開発プロセスを進めるという開発手法である。
【００１２】
また、形式手法とは、ソフトウェア開発における要求、仕様、設計の各段階を、論理的な矛盾がないように数学的に検証する手法のことである。開発に形式手法を用いた場合、ソフトウェアが行うべき論理的な振る舞いである要求仕様を、形式仕様記述と呼ばれる数式で記述しておき、これをソフトウェアの検証に用いる。以降、形式仕様記述で表されたソフトウェア仕様のことを、形式仕様と称する。
【００１３】
本発明では、この形式仕様から、プログラムを監視するためのソフトウェアモデルを自動生成する。また、生成したソフトウェアモデルからプログラムを自動生成して、監視対象のプログラムと同時に実行し監視させることで、任意の機能についての正確な自己診断機能を実現する。
【００１４】
本発明に係るコンピュータは、外部に接続されたセンサやスイッチ等から情報を取得する外部情報取得手段と、プログラムが実行される演算処理装置と、を有し、前記情報取得手段が取得した情報をもとに演算を行う演算プログラムと、仕様記述言語で記述された形式仕様記述から生成した監視プログラムと、が、前記演算処理装置上で実行され、前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理上に、要求仕様に定義されていない状態が発生していないか検証することを特徴とする。
【００１５】
組み込みソフトウェア開発において、モデルと形式手法を用いる場合、開発者は形式仕様を満たすようにソフトウェアモデルを設計し、ソフトウェアモデルから実行コードを生成する。そこで本発明では、形式仕様記述を、監視対象のソフトウェアモデルと同等のモデルに変換して監視プログラムを生成し、監視の用途に用いる。この監視を行うプログラムは、数理的に正しい形式仕様記述から自動生成されるため、ソフトウェアの実行結果が仕様通りであるかを判断することができる。これにより、開発者が自己診断機能のコーディングを行った場合と比較して、人為的なバグが混入する可能性が無くなるという利点がある。
【００１６】
また、本発明に係るソフトウェア作成装置は、プログラムの監視を行うための監視プログラムと、監視対象のプログラムである演算プログラムと、を生成可能なソフトウェア作成装置であって、該ソフトウェア作成装置は、プログラムの動作をモデル記述言語で記述
したモデル情報から、演算プログラムを生成する演算プログラム生成手段と、仕様記述言語で記述された形式仕様記述から監視プログラムを生成する監視プログラム生成手段と、前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、を有し、前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理上に、要求仕様に定義されていない状態が発生していないか検証可能であることを特徴とする。
【００１７】
このように構成することにより、前記自己診断機能を持つプログラムを作成し、実行用コンピュータに書き込むことができるソフトウェア作成装置を提供することができる。
【００１８】
また、前記ソフトウェア作成装置においては、前記形式仕様記述から前記監視プログラムを生成する際、監視に用いる形式仕様記述を選択できることを特徴としてもよい。
【００１９】
本発明における自己診断機能を備えたコンピュータは、監視対象のプログラムが持っている全ての機能に対して監視を実行すると、オーバーヘッドが大きくなり、オーバーヘッドを減らすと監視できる機能が少なくなるという問題がある。そこで、ソフトウェア作成装置が監視プログラムを生成する際に、監視に用いる形式仕様記述を選択可能にすることで、この問題に対応することができる。
【発明の効果】
【００２０】
本発明によれば、実行されるプログラムが要求仕様に従っているか効率よく監視を行うことができる、自己診断機能を備えたコンピュータ、ソフトウェア作成装置、およびソフトウェア作成方法を提供することができる。
【図面の簡単な説明】
【００２１】
【図１】開発環境におけるオブザーバモデルとシステムモデルを表す図である。
【図２】本発明におけるソフトウェア作成装置の構成を表す図である。
【図３】本発明におけるプログラムの構成を表す図である。
【図４】本発明におけるソフトウェア作成方法のフローチャートである。
【図５】第１の実施形態に係るコンピュータと、その周辺装置を表した図である。
【図６】第１の実施形態に係るプログラムの構成を詳細化した図である。
【図７】第２の実施形態に係る回路を表した図である。
【図８】第３の実施形態に係るオブザーバモデルとシステムモデルを表す図である。
【図９】第３の実施形態に係るプログラムの構成を表す図である。
【発明を実施するための形態】
【００２２】
形式手法を用いてソフトウェアの開発を行う場合、ソフトウェアが満たすべき要求を記述した形式仕様記述が、ソフトウェアの最も基本的な設計図となる。通常、形式仕様は、ＬＴＬ（Linear Temporal Logic）、ＣＴＬ（Computational Tree Logic）等の仕様記述
言語にて記述される。
【００２３】
また、形式手法を取り入れたモデルベース開発を行う場合、開発者が、ＭＡＴＬＡＢ（登録商標）、Ｓｉｍｕｌｉｎｋ（登録商標）等の開発ツール（以降、開発環境と称する）を用いて、形式仕様を満たすソフトウェアモデルを作成する。
【００２４】
作成したソフトウェアモデルに誤りがないことを検証するためには、モデルベーステストが用いられる。モデルベーステストとは、必要なテストをモデルレベルで実施するものであり、例えば、事前にテスト対象のパスを定義した試験用モデルを作成して、開発対象のモデルと対比させる方法や、実行結果を形式仕様と対比させて正しいことを確認してい
く方法など、いくつかの手法がある。
【００２５】
これらの手法の一つに、テスト対象のプログラムを監視するオブザーバモデルを作成する方法がある。オブザーバモデルとは、監視対象プログラムの入出力状態や変数などが、仕様通りとなっているか検証するための監視プログラムをモデルで表したものである。監視対象のプログラムは、この監視プログラムに対して、入出力状態や変数の更新といった状態変化のイベントを通知し、これを受けた監視プログラムが、当該状態変化が正しいか確認を行う。開発環境は、実環境を模した仮想環境であるため、監視対象のソフトウェアモデルから、監視対象プログラムをエミュレートすることができ、オブザーバモデルから、監視プログラムをエミュレートすることができる。そのため、開発環境において、モデル同士を組み合わせることで、監視対象プログラムの動作をテストすることができる。
【００２６】
一方、非特許文献１には、仕様記述言語であるＬＴＬにて記述された形式仕様を、有限オートマトンに変換する技術が開示されている。開発環境は、オートマトンで記述された情報を取り込み、モデル化することができるため、ソフトウェアの振る舞いが記録されている形式仕様をモデルに変換し、開発環境に組み込むことができる。これにより、前記オブザーバモデルを作成した場合と同等の効果が得られる。形式仕様は、全ての要求仕様が定義されているため、プログラムがある実行経路を辿った場合、それが仕様に定義されているものであるかを確認することができる。
【００２７】
検証が済んだソフトウェアモデルからは、非特許文献２および非特許文献３の技術を用いることにより、プログラム言語で記述されたコードを生成することができる。このコードをマイコンや車載コンピュータなどに書き込むことにより、実際の製品が作られる。
【００２８】
通常、ソフトウェアの開発工程においては、テストを実施した後は、試験用のモデルを除去したうえでコードを生成する。一方、本発明においては、設計したソフトウェアモデルと、形式仕様から生成したオブザーバモデルを組み合わせた状態のままでコードの生成を行う。開発環境上では、事前に想定された実行経路しか検証をすることができないが、ソフトウェアモデルと、形式仕様から生成したモデルを組み合わせた状態でコードを生成し、車載コンピュータなどの実環境に移すことで、プログラムが取り得る全ての実行経路について検証を行うことができるようになる。以降、形式仕様から生成したオブザーバモデルからコードを出力して、実行形式にしたものをランタイムオブザーバと称する。
【００２９】
出力されたランタイムオブザーバは、監視対象である演算プログラムと同時に実行され、演算に伴う状態の変化、つまり演算プログラムが有している変数や、入出力状態の変化を検出し、処理が仕様の定義に従っているかチェックを行う。万一、仕様に従っていない動作を検出した場合は、その旨を運転者に通知するとともに、詳細な情報を記録し、もしくは外部に送信することができる。必要があれば、システムの運用モードを変更、もしくは停止させることによって安全を担保してもよい。
【００３０】
（第１の実施形態）
第１の実施形態に係るコンピュータ、またはソフトウェア作成装置について、図１と図２を用いて詳細な説明をする。図１は、ソフトウェア作成装置におけるオブザーバモデルとシステムモデルとの関係を表す図であり、図２は、本発明におけるソフトウェア作成装置の構成を表した図である。形式仕様１１が、仕様記述言語で記述されたソフトウェアの要求仕様である。形式仕様には、ソフトウェアが満たすべき振る舞いが記録されており、たとえば「出力がオフの状態でスイッチを押したら必ずオンに遷移する。出力がオンの状態でスイッチを押したら必ずオフに遷移する」といった記述がされている。形式仕様１１は、要求仕様記憶部５１に記録されており、開発者はこの仕様を元に実際のソフトウェアモデルである全体システムモデル１３をソフトウェアモデル作成部５３にて作成する。
【００３１】
オブザーバモデル１２は、非特許文献１の技術により、形式仕様１１を有限オートマトンに変換したものである。変換はオブザーバモデル生成部５２によって実行される。オブザーバモデル１２は、開発環境に直接導入できる形式となっている。形式仕様１１から変換されたオブザーバモデル１２には、全ての要求仕様が定義されているため、オブザーバモデル１２を用いることによって、たとえば「出力がオフの状態でスイッチを押した結果、状態がオフであれば異常」といった判断をすることができる。
【００３２】
一方で、全体システムモデル１３の一部を構成するシステムモデル１４も同様に、有限オートマトンで表現できるソフトウェアモデルである。これは、開発者が実装を行ったものであり、数理的定義であるオブザーバモデル１２とは異なり、開発対象のシステムの処理や挙動が詳細に記録されている。たとえば「変数Ｘが０の状態で外部入力Ａから信号が入力されたら、外部出力Ｂから出力を行い、変数Ｘを１にする」といったように、仕様を実現するための具体的手段が記録されたものである。
【００３３】
開発環境では、システムモデル１４と、オブザーバモデル１２の双方の動作をエミュレートし、外部との入出力、たとえばエンジンの挙動をソフトウェアでシミュレートすることで、監視対象プログラムが仕様通りに動作することをモデルレベルで検証することが可能である。モデルの検証は、モデル検証部５４にて行うことができる。
【００３４】
通常の開発においては、システムモデル１４に係る機能を生成しようとした場合、システムモデル１４のみからコードを生成するが、本実施形態では、システムモデル１４と、オブザーバモデル１２を組み合わせた状態のまま、コードの出力を行う。両者を組み合わせたモデルを、オブザーバ連結モデル１０と称する。オブザーバ連結モデル１０は、開発環境における通常のソフトウェアモデルであるため、非特許文献２および非特許文献３に記載の技術により、Ｃ言語やハードウェア記述言語などのプログラム１７に変換することができる。コードの出力はコード生成部５５が行い、ソフトウェアモデルを入力すると、出力としてソースコードを得ることができる。
【００３５】
図３は、開発環境によって生成されたプログラムの構成を表す図である。システムモデル１４からは、演算プログラムである監視対象システム１５が、オブザーバモデル１２からは、監視プログラムであるランタイムオブザーバ１６が生成される。なお、監視対象システム１５と、ランタイムオブザーバ１６は、同時に実行するという条件を満たせば、一つのモジュールに格納されていてもよいし、複数のモジュールに分かれていてもよい。また、一つのプロセスであってもよいし、複数のプロセスに分かれて実行されてもよい。
【００３６】
出力されたコードは、コード書込部５６にて、実環境で動作するコンピュータが有する記憶装置３７（ＲＯＭ）に書き込まれる。本発明を車載コンピュータに適用する場合、実環境で動作するコンピュータとは主にエレクトロニックコントロールユニット（ＥＣＵ）を指す。本実施形態では、車載コンピュータを例に説明する。
【００３７】
図４は、第１の実施形態に係るソフトウェア開発手順を表したフロー図である。開発者は、形式仕様をオブザーバモデルに変換し（Ｓ１０）、形式仕様を元にソフトウェアモデルを設計する（Ｓ１１）。ステップＳ１０とステップＳ１１の手順は、どちらかを先に行ってもよいし、並列して行ってもよい。作成されたモデルは検証（Ｓ１２）されたのち、プログラムコードに変換される（Ｓ１３）。最終的に、生成されたコードを対象のコンピュータに書き込む（Ｓ１４）ことでソフトウェア開発が完了する。このうち、ステップＳ１０とＳ１３が開発環境による自動生成処理である。
【００３８】
次に、プログラムをコンピュータに書き込んだ後の動作を説明する。図５は、監視対象
システム１５およびランタイムオブザーバ１６が実行される車載コンピュータと、その周辺装置を表した図である。車載コンピュータ３４は、演算処理装置３６および記憶装置３７を有している。監視対象システム１５およびランタイムオブザーバ１６は、記憶装置３７に格納されており、演算処理装置３６にて実行される。監視対象システム１５は、入出力および変数の状態が変化するごとに、ランタイムオブザーバ１６にイベントを通知する。これにより、ランタイムオブザーバ１６は、イベントをトリガとして、監視対象システム１５が有する入出力および変数の状態が、要求仕様から外れていないかを確認することができる。
【００３９】
監視方法を具体的な例で説明する。図６は、第１の実施形態に係るプログラムの構成を詳細化した図である。車載コンピュータ３４は、センサ４１から信号を取得する外部情報取得手段、およびアクチュエータ４２へ信号を出力する外部情報出力手段を有している。ここで、監視対象システム１５が満たすべき要求仕様として「変数ＡおよびＢがともに１であるとき、センサ４１からの入力が０であれば、アクチュエータ４２への出力は１」というものがあった場合、ランタイムオブザーバ１６は、センサ４１からの入力状態、アクチュエータ４２への出力状態、変数Ａおよび変数Ｂを監視する。システム１５は、ランタイムオブザーバ１６に対して、入出力状態、および変数の内容が変化した場合、通知を行う。そして、ランタイムオブザーバ１６が、前記の仕様を満たさない状態、たとえば「変数ＡおよびＢがともに１、センサ４１からの入力が０、アクチュエータ４２への出力が０」という状態を検出した場合、仕様外の動作であると判定する。
【００４０】
ランタイムオブザーバが、仕様から外れた動作を検出した場合、コンピュータはその異常の度合いに応じて、対処を行う必要がある。例えば、車両を制御するオペレーティングシステムに不具合を検出した場合、システムを、運転に必要最低限な構成であるセーフモードに移行することが考えられる。運転の継続が不可能な不具合である場合、運転者に警告を与え、車両停止後にシステムをシャットダウンすることが考えられる。また、比較的安全と考えられる事象であった場合、運転者に通知のみを行ったうえで運転を継続してもよい。
【００４１】
仕様から外れた動作を検出した場合、車載コンピュータ３４は、ＬＥＤやＬＣＤなどの状態ディスプレイ３２を通じて、運転者に異常が発生した旨を通知する。また、車載コンピュータの内部記憶装置３５に、関連する情報をログとして記録する。不具合発生時の情報がメンテナンス時に役立つためである。記録する情報は、プログラムのメモリダンプや、各種レジスタの状態などが考えられる。また、これらのログ情報は、内部記憶装置３５に記録されるほか、外部通信装置３１を通して管理センター３８に通知してもよい。また、発生した事象が重大であり、運行に影響を与えると判断した場合は、車載コンピュータ３４は、システム制御部３３に対して信号を発し、システムの一部を制限したモード（セーフモード）に移行してもよい。
【００４２】
本実施形態によれば、数理的に正しい形式仕様を用いてランタイムオブザーバを生成し、プログラムを監視するため、処理において仕様から外れた状態が発生した場合、必ず検出することができるという利点がある。また、通常のモデルベーステストでは、考えられるケースを事前に定義して試験仕様を作らなくてはならないが、本発明では、エンドユーザが利用する実環境でプログラムを動作させながら監視を行うことができるため、テストで検出することができない予想外の不具合についても検出し、開発にフィードバックすることができるという利点がある。
【００４３】
また、仕様から外れた動作を検出した場合、運転者に通知するとともに、システムの状態を変更することで、安全を担保することができるという利点があり、事象発生時の詳細情報を記録、もしくは送信することにより、迅速なシステムの復旧が可能になるという利
点がある。
【００４４】
また、本実施形態にて例示したプログラム監視の内容は、プログラムの変数と外部入出力の内容のみをチェックする簡単なものであるが、形式仕様記述で表現できるソフトウェア仕様であれば、複雑なものであっても適用することができる。例えば、「次の読み込み時にセンサＡから１が入力された場合、今後どこかの時点で出力Ｂから１が出力されることが保証されるが、次の読み込み時にセンサＡから０が入力された場合、今後出力Ｂから１が出力されるかは保証されない。」といったものや、「センサＡから１が入力されるまで、出力Ｃからは０が出力され続けるが、センサＡからの入力が１となる状態が一度でもあった場合、出力Ｃからは１が出力され、メインスイッチを切らない限り保持し続ける」といった仕様も形式仕様記述にて表現することができる。
【００４５】
第１の実施形態においては、生成されたプログラムを車載コンピュータに書き込み、実際に自動車に搭載する例を挙げたが、実環境ではなく、仮想環境を用いて動作させてもよい。例えば、車載コンピュータに、エンジンをシミュレートするためのエンジンシミュレータを接続し、実際の自動車を模した環境でソフトウェアの試験を行ってもよい。
【００４６】
また、第１の実施形態においては、形式仕様記述からオブザーバモデルを作成し、オブザーバモデルからコードを生成したが、形式仕様記述から直接コードを生成してもよい。
【００４７】
（第２の実施形態）
図７は、第２の実施形態に係る回路を表した図である。第１の実施形態では、ランタイムオブザーバと、監視対象のプログラムは同一コンピュータの演算処理装置上にて動作するが、本実施形態では、ランタイムオブザーバと、監視対象のプログラムは共に独立したハードウェア上にて動作する。
【００４８】
本実施形態では第１の実施形態と同様に、ソフトウェア作成装置において、ソフトウェアモデルと、形式仕様から生成したオブザーバモデルを組み合わせた状態でコードの生成を行うが、コードはハードウェア記述言語で記述され、出力結果は集積回路等のデジタル回路に書き込まれる。このとき、演算プログラムと、監視プログラムは同一の集積回路に書き込んでもよいし、別個の集積回路に書き込んでもよい。
【００４９】
図７は、演算プログラムが書き込まれた集積回路と、監視プログラムが書き込まれた集積回路が別個となっている例である。監視対象回路１８は、監視対象となるプログラムが実行される回路であり、第１の実施形態における車載コンピュータ内の監視対象システム１５が置き換わるものである。また、ランタイムオブザーバ回路１９は、監視を行うプログラムが書き込まれた回路であり、第１の実施形態における車載コンピュータ内のランタイムオブザーバ１６が置き換わるものである。本実施形態では、ランタイムオブザーバ回路１９は、監視対象となる回路の入力信号および出力信号を監視し、入力信号の状態に変化があった場合、出力信号の状態確認を行う。出力信号に、仕様を外れた状態を検出した場合、異常信号線２０を通して外部への異常通報を行う。
【００５０】
異常通報がされた場合、コンピュータは、第１の実施形態と同様の対応をとることができる。なお、システム制御部３３は、システムの一部を制限したモードに移行する代わりに、異常が発生した回路をバイパス、もしくは切り離してもよい。
【００５１】
本実施形態のように構成することで、コンピュータ上ではなく、集積回路上で直接動作するプログラムにも、本発明を適用することができる。第１の実施形態が、同一のコンピュータ上で動作するのに対し、本実施形態ではランタイムオブザーバを別個の集積回路に書き込んでいるため、監視対象システムが動作する回路と、監視を行うランタイムオブザ
ーバが動作する回路を分離して設計することができるという利点を有している。
【００５２】
（第３の実施形態）
第３の実施形態について、図８を参照しながら説明する。第１の実施形態では、ソフトウェアモデルにオブザーバモデルを付加してコードを生成するため、プログラム上のオーバーヘッドが増大し、コンピュータのリソースを消費するという欠点がある。これを補うため、オブザーバモデルの生成時に、開発者が監視に用いる形式仕様記述を選択できるようにするのが本実施形態である。
【００５３】
形式仕様は、複数の数式で構成される。本実施形態では、燃料系、駆動系、安全装置系の各系統に対応する形式仕様記述があった場合を例として挙げる。通常、３種類全てに対応するランタイムオブザーバを生成するところ、オーバーヘッドの関係から許容される系統が２つまでという制限があった場合、たとえば開発者は、オブザーバモデル生成部５２に対して、駆動系と安全装置系の２種類に対応する形式仕様記述のみを指定することができる。
【００５４】
図８は、本実施形態におけるオブザーバモデルとシステムモデルを示した図である。駆動系および安全装置系の形式仕様記述のみを選択し、オブザーバモデル１２を作成した場合、ランタイムオブザーバ１６は、駆動系および安全装置系のみを監視するよう構成される。
【００５５】
一方、監視対象となるシステムモデルには、駆動系システムのモデル２７、安全装置系システムのモデル２８、燃料系システムのモデル２９がある。駆動系システムのモデル２７、安全装置系システムのモデル２８に対しては、図９に示したように、ランタイムオブザーバが生成されるため、開発者が診断のためのモデルを作成する必要はない。一方、燃料系システムのモデル２９について監視を行う場合は、開発者が別途診断のためのブロック３０を作成してもよい。この場合、燃料系の監視プログラムは、従来通りのダイアグノーシス機能２６として生成され、監視対象システム１５に組み込まれる。
【００５６】
本実施形態のように構成することで、信頼性の高いランタイムオブザーバには、安全のために最低限必要なもののみを搭載し、その他の、故障しても直ちに安全に影響しない機能については、従来通りに開発者が設計した診断機能（ダイアグノーシス）で対応するといった運用が可能になる。これにより、オーバーヘッドと安全性というトレードオフ関係の両立が可能となる。
【００５７】
第３の実施形態では、燃料系、駆動系、安全装置系のそれぞれの系統について、系統単位で監視の適用／非適用を指定したが、それぞれの形式仕様記述は複数の条件式から成っているため、条件式ごとに適用の有無を指定することができる。
【００５８】
なお、各実施形態の説明は本発明を説明する上での例示にすぎず、本発明を上記の実施形態に限定して解釈すべきではない。例えば、複数の実施形態を組み合わせてもよいし、仕様外の動作を検出した場合、第１の実施形態にて例示していない方法によって通知を行ってもよい。
【符号の説明】
【００５９】
１０ オブザーバ連結モデル
１１ 形式仕様
１２ オブザーバモデル
１３ 全体システムモデル
１４ 特定機能のシステムモデル
１５ 監視対象システム
１６ ランタイムオブザーバ
１７ プログラム
１８ 監視対象回路
１９ ランタイムオブザーバ回路
２０ 異常信号線
２６ 燃料系ダイアグノーシス機能
２７ 駆動系システムモデル
２８ 安全装置系システムモデル
２９ 燃料系システムモデル
３０ 燃料系診断ブロック
３１ 外部通信装置
３２ 状態ディスプレイ
３３ システム制御部
３４ 車載コンピュータ
３５ 内部記憶装置
３６ 演算処理装置
３７ 記憶装置（ＲＯＭ）
３８ 管理センター
４１ センサ
４２ アクチュエータ
５１ 要求仕様記憶部
５２ オブザーバモデル生成部
５３ ソフトウェアモデル作成部
５４ モデル検証部
５５ コード生成部
５６ コード書込部
【技術分野】
【０００１】
本発明は、自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置に関する。
【背景技術】
【０００２】
近年、自動車に搭載されているエレクトリックコントロールユニット（ＥＣＵ）のように、組み込みシステムを用いたコンピュータを車両に搭載することによって、ソフトウェアにて車両の状態を制御することが一般的になっている。
【０００３】
これらの車載コンピュータにおいては、制御している各種装置の故障や、それによる予期せぬ動作に起因する事故を防止するため、自己診断機能が備えられている場合が多い。自動車の場合、自己診断機能は「ダイアグノーシス（diagnosis）」や「ＯＢＤ（On-board diagnostics）」と呼ばれている。自己診断機能は、車載コンピュータに、仕様に定義
されていない信号が入力された等の異常な状態を検知して、運転者に通知し、コンピュータの内部記憶装置に詳細情報を記録するといった機能を持っている。
【０００４】
自己診断機能を備えたコンピュータの開発においては、定められたソフトウェア仕様を元に開発者が自己診断プログラムを設計し、診断対象のプログラムとあわせて実装する方法が一般的である。自己診断は、たとえば試験用の擬似入力信号を発生させ、それに対応する出力が仕様に沿ったものであるかプログラム内で検証するといった方法で実施される。
【０００５】
これらの自己診断機能は、診断対象となるプログラムが持つ機能ごとに設計と実装を行わなければならないため、主にコストの問題により、車載コンピュータが有する全機能を対象とするのではなく、例えば安全に関係する部分など、あらかじめ定められた範囲のみをチェックすることが一般的である。特許文献１においては、車両を制御するコンピュータに接続し、故障診断に必要なデータのみを採取する故障診断装置が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−１６６３２８号公報
【非特許文献】
【０００７】
【非特許文献１】Efficient translation of LTL formulae into Buchi automata, Dimitra Giannakopoulou, RIACS Technical Report 01.29, June 2001
【非特許文献２】“Simulink Coder”、［online］、MathWorks, Inc.、［平成２３年４月１５日検索］、インターネット＜ URL ：http://www.mathworks.co.jp/products/simulink-coder/index.html＞
【非特許文献３】“Simulink HDL Coder”、［online］、MathWorks, Inc.、［平成２３年４月１５日検索］、インターネット＜ URL ：http://http://www.mathworks.com/products/slhdlcoder/index.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
前述の自己診断機能は、車載コンピュータに接続されたセンサが正常に動作していることや、車載コンピュータの処理が正常に行えていることを、専用に設計されたプログラム
が監視する。しかし、コストの問題により、車載コンピュータが有する全ての機能を監視することは一般的ではなく、監視できない機能が少なからず存在するという問題がある。また、設計段階で、自己診断機能のプログラム自体にバグが混入する恐れがあるため、従来技術では、車載コンピュータの完全な自己診断を行うことができないという問題がある。
【０００９】
本発明は上記の問題点を考慮してなされたものであり、実行されるプログラムが要求仕様に従っているか効率よく監視を行うことができる、自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置では、上記目的を以下の手段により実現する。
【００１１】
組込みソフトウェアの開発においては、モデルベース開発、および形式手法が用いられる場合がある。モデルベース開発とは、統一モデリング言語等のモデル記述言語によって、コンピュータ上にソフトウェアの仕様を表現した仮想的なモデル（ソフトウェアモデル）を作り、モデルを検証しながら開発プロセスを進めるという開発手法である。
【００１２】
また、形式手法とは、ソフトウェア開発における要求、仕様、設計の各段階を、論理的な矛盾がないように数学的に検証する手法のことである。開発に形式手法を用いた場合、ソフトウェアが行うべき論理的な振る舞いである要求仕様を、形式仕様記述と呼ばれる数式で記述しておき、これをソフトウェアの検証に用いる。以降、形式仕様記述で表されたソフトウェア仕様のことを、形式仕様と称する。
【００１３】
本発明では、この形式仕様から、プログラムを監視するためのソフトウェアモデルを自動生成する。また、生成したソフトウェアモデルからプログラムを自動生成して、監視対象のプログラムと同時に実行し監視させることで、任意の機能についての正確な自己診断機能を実現する。
【００１４】
本発明に係るコンピュータは、外部に接続されたセンサやスイッチ等から情報を取得する外部情報取得手段と、プログラムが実行される演算処理装置と、を有し、前記情報取得手段が取得した情報をもとに演算を行う演算プログラムと、仕様記述言語で記述された形式仕様記述から生成した監視プログラムと、が、前記演算処理装置上で実行され、前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理上に、要求仕様に定義されていない状態が発生していないか検証することを特徴とする。
【００１５】
組み込みソフトウェア開発において、モデルと形式手法を用いる場合、開発者は形式仕様を満たすようにソフトウェアモデルを設計し、ソフトウェアモデルから実行コードを生成する。そこで本発明では、形式仕様記述を、監視対象のソフトウェアモデルと同等のモデルに変換して監視プログラムを生成し、監視の用途に用いる。この監視を行うプログラムは、数理的に正しい形式仕様記述から自動生成されるため、ソフトウェアの実行結果が仕様通りであるかを判断することができる。これにより、開発者が自己診断機能のコーディングを行った場合と比較して、人為的なバグが混入する可能性が無くなるという利点がある。
【００１６】
また、本発明に係るソフトウェア作成装置は、プログラムの監視を行うための監視プログラムと、監視対象のプログラムである演算プログラムと、を生成可能なソフトウェア作成装置であって、該ソフトウェア作成装置は、プログラムの動作をモデル記述言語で記述
したモデル情報から、演算プログラムを生成する演算プログラム生成手段と、仕様記述言語で記述された形式仕様記述から監視プログラムを生成する監視プログラム生成手段と、前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、を有し、前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理上に、要求仕様に定義されていない状態が発生していないか検証可能であることを特徴とする。
【００１７】
このように構成することにより、前記自己診断機能を持つプログラムを作成し、実行用コンピュータに書き込むことができるソフトウェア作成装置を提供することができる。
【００１８】
また、前記ソフトウェア作成装置においては、前記形式仕様記述から前記監視プログラムを生成する際、監視に用いる形式仕様記述を選択できることを特徴としてもよい。
【００１９】
本発明における自己診断機能を備えたコンピュータは、監視対象のプログラムが持っている全ての機能に対して監視を実行すると、オーバーヘッドが大きくなり、オーバーヘッドを減らすと監視できる機能が少なくなるという問題がある。そこで、ソフトウェア作成装置が監視プログラムを生成する際に、監視に用いる形式仕様記述を選択可能にすることで、この問題に対応することができる。
【発明の効果】
【００２０】
本発明によれば、実行されるプログラムが要求仕様に従っているか効率よく監視を行うことができる、自己診断機能を備えたコンピュータ、ソフトウェア作成装置、およびソフトウェア作成方法を提供することができる。
【図面の簡単な説明】
【００２１】
【図１】開発環境におけるオブザーバモデルとシステムモデルを表す図である。
【図２】本発明におけるソフトウェア作成装置の構成を表す図である。
【図３】本発明におけるプログラムの構成を表す図である。
【図４】本発明におけるソフトウェア作成方法のフローチャートである。
【図５】第１の実施形態に係るコンピュータと、その周辺装置を表した図である。
【図６】第１の実施形態に係るプログラムの構成を詳細化した図である。
【図７】第２の実施形態に係る回路を表した図である。
【図８】第３の実施形態に係るオブザーバモデルとシステムモデルを表す図である。
【図９】第３の実施形態に係るプログラムの構成を表す図である。
【発明を実施するための形態】
【００２２】
形式手法を用いてソフトウェアの開発を行う場合、ソフトウェアが満たすべき要求を記述した形式仕様記述が、ソフトウェアの最も基本的な設計図となる。通常、形式仕様は、ＬＴＬ（Linear Temporal Logic）、ＣＴＬ（Computational Tree Logic）等の仕様記述
言語にて記述される。
【００２３】
また、形式手法を取り入れたモデルベース開発を行う場合、開発者が、ＭＡＴＬＡＢ（登録商標）、Ｓｉｍｕｌｉｎｋ（登録商標）等の開発ツール（以降、開発環境と称する）を用いて、形式仕様を満たすソフトウェアモデルを作成する。
【００２４】
作成したソフトウェアモデルに誤りがないことを検証するためには、モデルベーステストが用いられる。モデルベーステストとは、必要なテストをモデルレベルで実施するものであり、例えば、事前にテスト対象のパスを定義した試験用モデルを作成して、開発対象のモデルと対比させる方法や、実行結果を形式仕様と対比させて正しいことを確認してい
く方法など、いくつかの手法がある。
【００２５】
これらの手法の一つに、テスト対象のプログラムを監視するオブザーバモデルを作成する方法がある。オブザーバモデルとは、監視対象プログラムの入出力状態や変数などが、仕様通りとなっているか検証するための監視プログラムをモデルで表したものである。監視対象のプログラムは、この監視プログラムに対して、入出力状態や変数の更新といった状態変化のイベントを通知し、これを受けた監視プログラムが、当該状態変化が正しいか確認を行う。開発環境は、実環境を模した仮想環境であるため、監視対象のソフトウェアモデルから、監視対象プログラムをエミュレートすることができ、オブザーバモデルから、監視プログラムをエミュレートすることができる。そのため、開発環境において、モデル同士を組み合わせることで、監視対象プログラムの動作をテストすることができる。
【００２６】
一方、非特許文献１には、仕様記述言語であるＬＴＬにて記述された形式仕様を、有限オートマトンに変換する技術が開示されている。開発環境は、オートマトンで記述された情報を取り込み、モデル化することができるため、ソフトウェアの振る舞いが記録されている形式仕様をモデルに変換し、開発環境に組み込むことができる。これにより、前記オブザーバモデルを作成した場合と同等の効果が得られる。形式仕様は、全ての要求仕様が定義されているため、プログラムがある実行経路を辿った場合、それが仕様に定義されているものであるかを確認することができる。
【００２７】
検証が済んだソフトウェアモデルからは、非特許文献２および非特許文献３の技術を用いることにより、プログラム言語で記述されたコードを生成することができる。このコードをマイコンや車載コンピュータなどに書き込むことにより、実際の製品が作られる。
【００２８】
通常、ソフトウェアの開発工程においては、テストを実施した後は、試験用のモデルを除去したうえでコードを生成する。一方、本発明においては、設計したソフトウェアモデルと、形式仕様から生成したオブザーバモデルを組み合わせた状態のままでコードの生成を行う。開発環境上では、事前に想定された実行経路しか検証をすることができないが、ソフトウェアモデルと、形式仕様から生成したモデルを組み合わせた状態でコードを生成し、車載コンピュータなどの実環境に移すことで、プログラムが取り得る全ての実行経路について検証を行うことができるようになる。以降、形式仕様から生成したオブザーバモデルからコードを出力して、実行形式にしたものをランタイムオブザーバと称する。
【００２９】
出力されたランタイムオブザーバは、監視対象である演算プログラムと同時に実行され、演算に伴う状態の変化、つまり演算プログラムが有している変数や、入出力状態の変化を検出し、処理が仕様の定義に従っているかチェックを行う。万一、仕様に従っていない動作を検出した場合は、その旨を運転者に通知するとともに、詳細な情報を記録し、もしくは外部に送信することができる。必要があれば、システムの運用モードを変更、もしくは停止させることによって安全を担保してもよい。
【００３０】
（第１の実施形態）
第１の実施形態に係るコンピュータ、またはソフトウェア作成装置について、図１と図２を用いて詳細な説明をする。図１は、ソフトウェア作成装置におけるオブザーバモデルとシステムモデルとの関係を表す図であり、図２は、本発明におけるソフトウェア作成装置の構成を表した図である。形式仕様１１が、仕様記述言語で記述されたソフトウェアの要求仕様である。形式仕様には、ソフトウェアが満たすべき振る舞いが記録されており、たとえば「出力がオフの状態でスイッチを押したら必ずオンに遷移する。出力がオンの状態でスイッチを押したら必ずオフに遷移する」といった記述がされている。形式仕様１１は、要求仕様記憶部５１に記録されており、開発者はこの仕様を元に実際のソフトウェアモデルである全体システムモデル１３をソフトウェアモデル作成部５３にて作成する。
【００３１】
オブザーバモデル１２は、非特許文献１の技術により、形式仕様１１を有限オートマトンに変換したものである。変換はオブザーバモデル生成部５２によって実行される。オブザーバモデル１２は、開発環境に直接導入できる形式となっている。形式仕様１１から変換されたオブザーバモデル１２には、全ての要求仕様が定義されているため、オブザーバモデル１２を用いることによって、たとえば「出力がオフの状態でスイッチを押した結果、状態がオフであれば異常」といった判断をすることができる。
【００３２】
一方で、全体システムモデル１３の一部を構成するシステムモデル１４も同様に、有限オートマトンで表現できるソフトウェアモデルである。これは、開発者が実装を行ったものであり、数理的定義であるオブザーバモデル１２とは異なり、開発対象のシステムの処理や挙動が詳細に記録されている。たとえば「変数Ｘが０の状態で外部入力Ａから信号が入力されたら、外部出力Ｂから出力を行い、変数Ｘを１にする」といったように、仕様を実現するための具体的手段が記録されたものである。
【００３３】
開発環境では、システムモデル１４と、オブザーバモデル１２の双方の動作をエミュレートし、外部との入出力、たとえばエンジンの挙動をソフトウェアでシミュレートすることで、監視対象プログラムが仕様通りに動作することをモデルレベルで検証することが可能である。モデルの検証は、モデル検証部５４にて行うことができる。
【００３４】
通常の開発においては、システムモデル１４に係る機能を生成しようとした場合、システムモデル１４のみからコードを生成するが、本実施形態では、システムモデル１４と、オブザーバモデル１２を組み合わせた状態のまま、コードの出力を行う。両者を組み合わせたモデルを、オブザーバ連結モデル１０と称する。オブザーバ連結モデル１０は、開発環境における通常のソフトウェアモデルであるため、非特許文献２および非特許文献３に記載の技術により、Ｃ言語やハードウェア記述言語などのプログラム１７に変換することができる。コードの出力はコード生成部５５が行い、ソフトウェアモデルを入力すると、出力としてソースコードを得ることができる。
【００３５】
図３は、開発環境によって生成されたプログラムの構成を表す図である。システムモデル１４からは、演算プログラムである監視対象システム１５が、オブザーバモデル１２からは、監視プログラムであるランタイムオブザーバ１６が生成される。なお、監視対象システム１５と、ランタイムオブザーバ１６は、同時に実行するという条件を満たせば、一つのモジュールに格納されていてもよいし、複数のモジュールに分かれていてもよい。また、一つのプロセスであってもよいし、複数のプロセスに分かれて実行されてもよい。
【００３６】
出力されたコードは、コード書込部５６にて、実環境で動作するコンピュータが有する記憶装置３７（ＲＯＭ）に書き込まれる。本発明を車載コンピュータに適用する場合、実環境で動作するコンピュータとは主にエレクトロニックコントロールユニット（ＥＣＵ）を指す。本実施形態では、車載コンピュータを例に説明する。
【００３７】
図４は、第１の実施形態に係るソフトウェア開発手順を表したフロー図である。開発者は、形式仕様をオブザーバモデルに変換し（Ｓ１０）、形式仕様を元にソフトウェアモデルを設計する（Ｓ１１）。ステップＳ１０とステップＳ１１の手順は、どちらかを先に行ってもよいし、並列して行ってもよい。作成されたモデルは検証（Ｓ１２）されたのち、プログラムコードに変換される（Ｓ１３）。最終的に、生成されたコードを対象のコンピュータに書き込む（Ｓ１４）ことでソフトウェア開発が完了する。このうち、ステップＳ１０とＳ１３が開発環境による自動生成処理である。
【００３８】
次に、プログラムをコンピュータに書き込んだ後の動作を説明する。図５は、監視対象
システム１５およびランタイムオブザーバ１６が実行される車載コンピュータと、その周辺装置を表した図である。車載コンピュータ３４は、演算処理装置３６および記憶装置３７を有している。監視対象システム１５およびランタイムオブザーバ１６は、記憶装置３７に格納されており、演算処理装置３６にて実行される。監視対象システム１５は、入出力および変数の状態が変化するごとに、ランタイムオブザーバ１６にイベントを通知する。これにより、ランタイムオブザーバ１６は、イベントをトリガとして、監視対象システム１５が有する入出力および変数の状態が、要求仕様から外れていないかを確認することができる。
【００３９】
監視方法を具体的な例で説明する。図６は、第１の実施形態に係るプログラムの構成を詳細化した図である。車載コンピュータ３４は、センサ４１から信号を取得する外部情報取得手段、およびアクチュエータ４２へ信号を出力する外部情報出力手段を有している。ここで、監視対象システム１５が満たすべき要求仕様として「変数ＡおよびＢがともに１であるとき、センサ４１からの入力が０であれば、アクチュエータ４２への出力は１」というものがあった場合、ランタイムオブザーバ１６は、センサ４１からの入力状態、アクチュエータ４２への出力状態、変数Ａおよび変数Ｂを監視する。システム１５は、ランタイムオブザーバ１６に対して、入出力状態、および変数の内容が変化した場合、通知を行う。そして、ランタイムオブザーバ１６が、前記の仕様を満たさない状態、たとえば「変数ＡおよびＢがともに１、センサ４１からの入力が０、アクチュエータ４２への出力が０」という状態を検出した場合、仕様外の動作であると判定する。
【００４０】
ランタイムオブザーバが、仕様から外れた動作を検出した場合、コンピュータはその異常の度合いに応じて、対処を行う必要がある。例えば、車両を制御するオペレーティングシステムに不具合を検出した場合、システムを、運転に必要最低限な構成であるセーフモードに移行することが考えられる。運転の継続が不可能な不具合である場合、運転者に警告を与え、車両停止後にシステムをシャットダウンすることが考えられる。また、比較的安全と考えられる事象であった場合、運転者に通知のみを行ったうえで運転を継続してもよい。
【００４１】
仕様から外れた動作を検出した場合、車載コンピュータ３４は、ＬＥＤやＬＣＤなどの状態ディスプレイ３２を通じて、運転者に異常が発生した旨を通知する。また、車載コンピュータの内部記憶装置３５に、関連する情報をログとして記録する。不具合発生時の情報がメンテナンス時に役立つためである。記録する情報は、プログラムのメモリダンプや、各種レジスタの状態などが考えられる。また、これらのログ情報は、内部記憶装置３５に記録されるほか、外部通信装置３１を通して管理センター３８に通知してもよい。また、発生した事象が重大であり、運行に影響を与えると判断した場合は、車載コンピュータ３４は、システム制御部３３に対して信号を発し、システムの一部を制限したモード（セーフモード）に移行してもよい。
【００４２】
本実施形態によれば、数理的に正しい形式仕様を用いてランタイムオブザーバを生成し、プログラムを監視するため、処理において仕様から外れた状態が発生した場合、必ず検出することができるという利点がある。また、通常のモデルベーステストでは、考えられるケースを事前に定義して試験仕様を作らなくてはならないが、本発明では、エンドユーザが利用する実環境でプログラムを動作させながら監視を行うことができるため、テストで検出することができない予想外の不具合についても検出し、開発にフィードバックすることができるという利点がある。
【００４３】
また、仕様から外れた動作を検出した場合、運転者に通知するとともに、システムの状態を変更することで、安全を担保することができるという利点があり、事象発生時の詳細情報を記録、もしくは送信することにより、迅速なシステムの復旧が可能になるという利
点がある。
【００４４】
また、本実施形態にて例示したプログラム監視の内容は、プログラムの変数と外部入出力の内容のみをチェックする簡単なものであるが、形式仕様記述で表現できるソフトウェア仕様であれば、複雑なものであっても適用することができる。例えば、「次の読み込み時にセンサＡから１が入力された場合、今後どこかの時点で出力Ｂから１が出力されることが保証されるが、次の読み込み時にセンサＡから０が入力された場合、今後出力Ｂから１が出力されるかは保証されない。」といったものや、「センサＡから１が入力されるまで、出力Ｃからは０が出力され続けるが、センサＡからの入力が１となる状態が一度でもあった場合、出力Ｃからは１が出力され、メインスイッチを切らない限り保持し続ける」といった仕様も形式仕様記述にて表現することができる。
【００４５】
第１の実施形態においては、生成されたプログラムを車載コンピュータに書き込み、実際に自動車に搭載する例を挙げたが、実環境ではなく、仮想環境を用いて動作させてもよい。例えば、車載コンピュータに、エンジンをシミュレートするためのエンジンシミュレータを接続し、実際の自動車を模した環境でソフトウェアの試験を行ってもよい。
【００４６】
また、第１の実施形態においては、形式仕様記述からオブザーバモデルを作成し、オブザーバモデルからコードを生成したが、形式仕様記述から直接コードを生成してもよい。
【００４７】
（第２の実施形態）
図７は、第２の実施形態に係る回路を表した図である。第１の実施形態では、ランタイムオブザーバと、監視対象のプログラムは同一コンピュータの演算処理装置上にて動作するが、本実施形態では、ランタイムオブザーバと、監視対象のプログラムは共に独立したハードウェア上にて動作する。
【００４８】
本実施形態では第１の実施形態と同様に、ソフトウェア作成装置において、ソフトウェアモデルと、形式仕様から生成したオブザーバモデルを組み合わせた状態でコードの生成を行うが、コードはハードウェア記述言語で記述され、出力結果は集積回路等のデジタル回路に書き込まれる。このとき、演算プログラムと、監視プログラムは同一の集積回路に書き込んでもよいし、別個の集積回路に書き込んでもよい。
【００４９】
図７は、演算プログラムが書き込まれた集積回路と、監視プログラムが書き込まれた集積回路が別個となっている例である。監視対象回路１８は、監視対象となるプログラムが実行される回路であり、第１の実施形態における車載コンピュータ内の監視対象システム１５が置き換わるものである。また、ランタイムオブザーバ回路１９は、監視を行うプログラムが書き込まれた回路であり、第１の実施形態における車載コンピュータ内のランタイムオブザーバ１６が置き換わるものである。本実施形態では、ランタイムオブザーバ回路１９は、監視対象となる回路の入力信号および出力信号を監視し、入力信号の状態に変化があった場合、出力信号の状態確認を行う。出力信号に、仕様を外れた状態を検出した場合、異常信号線２０を通して外部への異常通報を行う。
【００５０】
異常通報がされた場合、コンピュータは、第１の実施形態と同様の対応をとることができる。なお、システム制御部３３は、システムの一部を制限したモードに移行する代わりに、異常が発生した回路をバイパス、もしくは切り離してもよい。
【００５１】
本実施形態のように構成することで、コンピュータ上ではなく、集積回路上で直接動作するプログラムにも、本発明を適用することができる。第１の実施形態が、同一のコンピュータ上で動作するのに対し、本実施形態ではランタイムオブザーバを別個の集積回路に書き込んでいるため、監視対象システムが動作する回路と、監視を行うランタイムオブザ
ーバが動作する回路を分離して設計することができるという利点を有している。
【００５２】
（第３の実施形態）
第３の実施形態について、図８を参照しながら説明する。第１の実施形態では、ソフトウェアモデルにオブザーバモデルを付加してコードを生成するため、プログラム上のオーバーヘッドが増大し、コンピュータのリソースを消費するという欠点がある。これを補うため、オブザーバモデルの生成時に、開発者が監視に用いる形式仕様記述を選択できるようにするのが本実施形態である。
【００５３】
形式仕様は、複数の数式で構成される。本実施形態では、燃料系、駆動系、安全装置系の各系統に対応する形式仕様記述があった場合を例として挙げる。通常、３種類全てに対応するランタイムオブザーバを生成するところ、オーバーヘッドの関係から許容される系統が２つまでという制限があった場合、たとえば開発者は、オブザーバモデル生成部５２に対して、駆動系と安全装置系の２種類に対応する形式仕様記述のみを指定することができる。
【００５４】
図８は、本実施形態におけるオブザーバモデルとシステムモデルを示した図である。駆動系および安全装置系の形式仕様記述のみを選択し、オブザーバモデル１２を作成した場合、ランタイムオブザーバ１６は、駆動系および安全装置系のみを監視するよう構成される。
【００５５】
一方、監視対象となるシステムモデルには、駆動系システムのモデル２７、安全装置系システムのモデル２８、燃料系システムのモデル２９がある。駆動系システムのモデル２７、安全装置系システムのモデル２８に対しては、図９に示したように、ランタイムオブザーバが生成されるため、開発者が診断のためのモデルを作成する必要はない。一方、燃料系システムのモデル２９について監視を行う場合は、開発者が別途診断のためのブロック３０を作成してもよい。この場合、燃料系の監視プログラムは、従来通りのダイアグノーシス機能２６として生成され、監視対象システム１５に組み込まれる。
【００５６】
本実施形態のように構成することで、信頼性の高いランタイムオブザーバには、安全のために最低限必要なもののみを搭載し、その他の、故障しても直ちに安全に影響しない機能については、従来通りに開発者が設計した診断機能（ダイアグノーシス）で対応するといった運用が可能になる。これにより、オーバーヘッドと安全性というトレードオフ関係の両立が可能となる。
【００５７】
第３の実施形態では、燃料系、駆動系、安全装置系のそれぞれの系統について、系統単位で監視の適用／非適用を指定したが、それぞれの形式仕様記述は複数の条件式から成っているため、条件式ごとに適用の有無を指定することができる。
【００５８】
なお、各実施形態の説明は本発明を説明する上での例示にすぎず、本発明を上記の実施形態に限定して解釈すべきではない。例えば、複数の実施形態を組み合わせてもよいし、仕様外の動作を検出した場合、第１の実施形態にて例示していない方法によって通知を行ってもよい。
【符号の説明】
【００５９】
１０ オブザーバ連結モデル
１１ 形式仕様
１２ オブザーバモデル
１３ 全体システムモデル
１４ 特定機能のシステムモデル
１５ 監視対象システム
１６ ランタイムオブザーバ
１７ プログラム
１８ 監視対象回路
１９ ランタイムオブザーバ回路
２０ 異常信号線
２６ 燃料系ダイアグノーシス機能
２７ 駆動系システムモデル
２８ 安全装置系システムモデル
２９ 燃料系システムモデル
３０ 燃料系診断ブロック
３１ 外部通信装置
３２ 状態ディスプレイ
３３ システム制御部
３４ 車載コンピュータ
３５ 内部記憶装置
３６ 演算処理装置
３７ 記憶装置（ＲＯＭ）
３８ 管理センター
４１ センサ
４２ アクチュエータ
５１ 要求仕様記憶部
５２ オブザーバモデル生成部
５３ ソフトウェアモデル作成部
５４ モデル検証部
５５ コード生成部
５６ コード書込部
【特許請求の範囲】
【請求項１】
外部機器から情報を取得する外部情報取得手段と、
プログラムを実行する演算処理装置と、
を有し、
前記外部情報取得手段が取得した情報をもとに演算を行う演算プログラムと、
要求仕様を仕様記述言語で記述した形式仕様記述から生成された監視プログラムと、
が、前記演算処理装置上で実行され、
前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、
前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理が、要求仕様の定義に従っているか否かを検証する
ことを特徴とする、自己診断機能を備えたコンピュータ。
【請求項２】
プログラムの監視を行うための監視プログラムと、監視対象のプログラムである演算プログラムと、
を生成可能なソフトウェア作成装置であって、
該ソフトウェア作成装置は、
プログラムの動作をモデル記述言語で記述したモデル情報から、演算プログラムを生成する演算プログラム生成手段と、
要求仕様を仕様記述言語で記述した形式仕様記述から監視プログラムを生成する監視プログラム生成手段と、
前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、
を有し、
前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、
前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理上に、要求仕様に定義されていない状態が発生していないか検証可能である
ことを特徴とする、ソフトウェア作成装置。
【請求項３】
利用者が監視に用いる形式仕様記述を選択するための選択手段をさらに有し、
前記監視プログラム生成手段は、
前記形式仕様記述から前記監視プログラムを生成する際、選択された前記形式仕様記述を用いて前記監視プログラムを生成する
ことを特徴とする、請求項２に記載のソフトウェア作成装置。
【請求項４】
プログラムの監視を行うための監視プログラムを生成する監視プログラム生成手段と、
監視対象のプログラムである演算プログラムを生成する演算プログラム生成手段と、
を有するソフトウェア作成装置が行うソフトウェア作成方法であって、
演算に伴う状態の変化を前記監視プログラムに通知する前記演算プログラムを、プログラムの動作をモデル記述言語で記述したモデル情報から生成するステップと、
前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理が要求仕様に従っているか否かを検証する前記監視プログラムを、要求仕様を仕様記述言語で記述した形式仕様記述から生成するステップと、
を含む
ことを特徴とする、ソフトウェア作成方法。
【請求項１】
外部機器から情報を取得する外部情報取得手段と、
プログラムを実行する演算処理装置と、
を有し、
前記外部情報取得手段が取得した情報をもとに演算を行う演算プログラムと、
要求仕様を仕様記述言語で記述した形式仕様記述から生成された監視プログラムと、
が、前記演算処理装置上で実行され、
前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、
前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理が、要求仕様の定義に従っているか否かを検証する
ことを特徴とする、自己診断機能を備えたコンピュータ。
【請求項２】
プログラムの監視を行うための監視プログラムと、監視対象のプログラムである演算プログラムと、
を生成可能なソフトウェア作成装置であって、
該ソフトウェア作成装置は、
プログラムの動作をモデル記述言語で記述したモデル情報から、演算プログラムを生成する演算プログラム生成手段と、
要求仕様を仕様記述言語で記述した形式仕様記述から監視プログラムを生成する監視プログラム生成手段と、
前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、
を有し、
前記演算プログラムは、演算に伴う状態の変化を前記監視プログラムに通知し、
前記監視プログラムは、前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理上に、要求仕様に定義されていない状態が発生していないか検証可能である
ことを特徴とする、ソフトウェア作成装置。
【請求項３】
利用者が監視に用いる形式仕様記述を選択するための選択手段をさらに有し、
前記監視プログラム生成手段は、
前記形式仕様記述から前記監視プログラムを生成する際、選択された前記形式仕様記述を用いて前記監視プログラムを生成する
ことを特徴とする、請求項２に記載のソフトウェア作成装置。
【請求項４】
プログラムの監視を行うための監視プログラムを生成する監視プログラム生成手段と、
監視対象のプログラムである演算プログラムを生成する演算プログラム生成手段と、
を有するソフトウェア作成装置が行うソフトウェア作成方法であって、
演算に伴う状態の変化を前記監視プログラムに通知する前記演算プログラムを、プログラムの動作をモデル記述言語で記述したモデル情報から生成するステップと、
前記演算プログラムからの通知をトリガとして、前記演算プログラムの処理が要求仕様に従っているか否かを検証する前記監視プログラムを、要求仕様を仕様記述言語で記述した形式仕様記述から生成するステップと、
を含む
ことを特徴とする、ソフトウェア作成方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−７７０４８（Ｐ２０１３−７７０４８Ａ）
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願番号】特願２０１１−２１４９９２（Ｐ２０１１−２１４９９２）
【出願日】平成２３年９月２９日（２０１１．９．２９）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（５１１２３６０１７）ＢＴＣ Ｊａｐａｎ株式会社 (1)
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【Ｆターム（参考）】
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願日】平成２３年９月２９日（２０１１．９．２９）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（５１１２３６０１７）ＢＴＣ Ｊａｐａｎ株式会社 (1)
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【Ｆターム（参考）】
[ Back to top ]