JP5714543B2

JP5714543B2 - 自己監視機能を備えたコンピュータ、監視プログラム

Info

Publication number: JP5714543B2
Application number: JP2012184540A
Authority: JP
Inventors: 真一白石; 正治明井; 太一安藤
Original assignee: Btc Japan
Current assignee: Btc Japan
Priority date: 2012-08-23
Filing date: 2012-08-23
Publication date: 2015-05-07
Anticipated expiration: 2032-08-23
Also published as: EP2889775A1; CN104583969B; US9588878B2; EP2889775A4; US20150261660A1; EP2889775B1; WO2014030707A1; JP2014041554A; CN104583969A

Description

本発明は、自己監視機能を備えたコンピュータ、および監視プログラムに関する。

近年、組み込みシステムによって機器の状態を制御することが一般的になっている。例えば、自動車に搭載されたコンピュータは、ＥＣＵ（エレクトリックコントロールユニット）と呼ばれ、走行に関する様々な制御を行っている。このような組み込みシステムによる制御用コンピュータは、工場プラントや製造ラインなど、自動車以外の分野においても数多く利用されている。

ＥＣＵをはじめとする制御用コンピュータにおいては、仕様に従って正しくプログラムが動作していることを保証する必要がある。回路の故障やプログラムの不具合によって予期せぬ動作が発生すると、車両やラインを正常に制御することができなくなり、利用者の安全を脅かすためである。

制御用のコンピュータにおいては、故障や不具合に起因する事故を防止するため、自己診断機能が備えられている場合が多い。自動車の場合、自己診断機能は「ダイアグノーシス（diagnosis）」や「ＯＢＤ（On-board diagnostics）」と呼ばれている（非特許文献
１参照）。自己診断機能は、コンピュータの内部で、定義されていない信号が発生した等の異常な状態を検知して、利用者への警告やシステムの停止、ログ情報の記録などをすることができる。

" ODB-II On-Board Diagnostics"、［online］、B&B Electronics、［平成２４年７月２３日検索］、インターネット＜URL：http://www.obdii.com/＞

前述したような自己診断機能を有するコンピュータは、回路の故障やプログラムの不具合による異常動作を検出し、利用者に警告することができる。しかし、自己診断機能は、システムが異常な状態となったことを検知することはできるが、システムが異常動作に至る前の、いわゆる「検証されていない状態」であることを検出することはできない。

この問題について詳しく説明する。一般的に、ソフトウェアのテストにおいては、利用者が行う操作を想定してテストシナリオを生成する。しかし、全てのケースを完全に網羅することは容易ではなく、想定されていない操作が行われることが少なからずある。このような想定外の操作が行われた場合、ソフトウェアは検証されていないシナリオを処理することとなるため、正常に処理が行えるかが保証できない。すなわち、当該シナリオにおいて不具合が発生し、システムが不安定になったり、異常動作を引き起こしたりする可能性がある。このような未検証の状態は、クリティカルな状態ではないものの、ソフトウェアの動作上リスクを抱えた状態であるため、積極的に検出して通知を行うことが望ましい。しかし、コンピュータで動作中のプログラムが、検証済みのシナリオに沿って動作しているのか否かについては、従来の技術では検出することができなかった。

本発明は上記の問題点を考慮してなされたものであり、利用者がテストシナリオに存在しない操作を行ったことを検出することができる、自己監視機能を備えたコンピュータ、
および監視プログラムを提供することを目的とする。

本発明の第一の形態は、自己監視機能を備えたコンピュータである。
本発明の第一の形態に係るコンピュータは、入力操作を取得する入力手段と、前記入力手段が取得した入力操作をもとに演算を行う演算プログラムが実行される第一のプログラム実行手段と、前記演算プログラムに対する複数のテストシナリオを記憶したテストシナリオ記憶手段と、前記入力手段が取得した入力操作が、前記記憶された複数のテストシナリオのうち、いずれかと対応するものであるかを判定する監視プログラムが実行される第二のプログラム実行手段と、を有することを特徴とする。

演算プログラムとは、監視の対象となるプログラムであり、コンピュータに備えられた入力手段を通して取得された入力操作に基づいて演算を行うプログラムである。入力手段とは、マウス、タッチパネル、キーボード等のヒューマンインタフェースデバイスであり、入力操作とは、当該デバイスを通して利用者から入力された情報を指す。具体的には、クリック、タップ、キー押下などのハードウェアと直接関連付いたイベントであってもよいし、テキストボックス、ドロップダウンリスト、スライダなどのＧＵＩ（Graphical User Interface）部品を通して入力される値であってもよい。

また、監視プログラムとは、利用者による入力操作を取得し、当該入力操作が検証済みであるか否かを判定するプログラムである。入力操作が検証済みであるか否かの判定は、取得した入力操作と、記憶している複数のテストシナリオとを対比させることで行う。テストシナリオとは、演算プログラムのテストに係る操作が記録されたデータであり、監視プログラムは、取得した入力操作と、テストシナリオに記録された操作の内容が一致するかを確認することで、当該入力操作が検証済みであるか否かを判定することができる。

また、前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含むことを特徴としてもよく、前記監視プログラムは、前記入力手段から複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定することを特徴としてもよい。

このように、検証の対象は複数の入力操作であってもよい。すなわち、入力手段から順次入力される操作と、テストシナリオに時系列順に記録された操作とを比較し、その内容および順序が一致しているかを検証することで、入力された操作がテストシナリオに対応したものであるかを判定することができる。

また、前記監視プログラムは、前記取得した入力操作が、記憶した複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知することを特徴としてもよい。

利用者が行った操作が、記憶している複数のテストシナリオのいずれとも対応しない場合、当該操作は検証されていない操作であると判定できる。この場合、監視プログラムが、演算プログラムや外部プログラムに対して、動作が検証されていない状況であることを通知する。これにより、例えば、システムログへの出力、外部システムへの通知、セーフモードへの移行など、異常発生に備えた処理を行うことができ、システムの安全を担保することができる。

本発明の第二の形態は、任意のプログラムを監視する監視プログラムである。
本発明の第二の形態に係る監視プログラムは、演算を行う演算プログラムと同時に実行
され、前記演算プログラムに対する入力操作を監視する監視プログラムであって、前記演算プログラムに対する入力操作を取得する入力取得ステップと、前記取得した入力操作が、事前に記憶された、前記演算プログラムに対する複数のテストシナリオのうちいずれかと対応するものであるかを判定する入力判定ステップと、を含むことを特徴とする。

また、前記記憶された各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含むことを特徴としてもよく、前記入力取得ステップは、前記入力判定ステップは、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定することを特徴としてもよい。

また、前記入力判定ステップにおいて、前記取得した入力操作が、記憶された複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知するステップを実行することを特徴としてもよい。

このように、本発明は、任意のプログラムに対する入力操作を監視する監視プログラムとして特定することもできる。

本発明の第三の形態は、演算を行う演算プログラムと、前記演算プログラムに対する入力操作を監視する監視プログラムと、を生成するソフトウェア作成装置である。
本発明の第三の形態に係るソフトウェア作成装置は、前記演算プログラムのコード入力を受け付ける演算プログラム入力手段と、モデリング言語によって記述された、前記演算プログラムに対する複数のテストシナリオの入力を受け付けるテストシナリオ入力手段と、前記演算プログラムを生成する演算プログラム生成手段と、前記複数のテストシナリオを含み、前記演算プログラムに対する入力操作が、前記複数のテストシナリオのうちいずれかと対応するものであるかを判定する監視プログラムを生成する監視プログラム生成手段と、前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、を有し、前記演算プログラム生成手段は、前記演算プログラムに対し、前記演算プログラムが行う所定の処理をトリガとして、前記演算プログラムに対して行われた入力操作を前記監視プログラムに通知する処理を追加することを特徴とする。

また、前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含むことを特徴としてもよく、前記監視プログラムは、複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定することを特徴としてもよい。

また、前記監視プログラムは、前記入力操作が、複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知可能であることを特徴としてもよい。

このように、本発明は、本発明の第一の形態に係るコンピュータに、演算プログラムおよび監視プログラムを記録するソフトウェア作成装置として特定することもできる。なお、上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

本発明によれば、利用者がテストシナリオに存在しない操作を行ったことを検出することができる、自己監視機能を備えたコンピュータ、および監視プログラムを提供すること
ができる。

オブザーバコードおよびアプリケーションコードの作成方法を説明する図である。本発明におけるソフトウェア作成装置のシステム構成図である。本発明における実行プログラムの構成を表す図である。ソフトウェア開発のフローチャートである。第一の実施形態に係るコンピュータのシステム構成図である。プログラムの監視に用いるテストシナリオの例である。入力操作によるプログラムの状態遷移を説明する図である。第一の実施形態に係るコンピュータの処理フローチャートである。第二の実施形態に係る回路構成を表した図である。

（第一の実施形態）
<プログラム開発方法の概要>
本発明に係る監視プログラム、および監視対象となる演算プログラムの開発方法について概要を説明する。図１は、本発明に係る演算プログラムおよび監視プログラムの作成方法を説明する図である。本実施形態では、オープンソースで提供されている統合開発環境であるＥｃｌｉｐｓｅを用いて、Ｊａｖａ（登録商標）アプリケーションを作成する例について述べる。

ソフトウェアを作成する際は、設計の基礎となるソフトウェア要件（符号１０）を最初に定義する必要がある。ソフトウェア要件とは、ソフトウェアが満たすべき要求を定義したものである。ソフトウェア要件は、自然言語によって記述してもよいし、コンピュータが直接解釈できる仕様記述言語などの言語によって記述してもよい。

ソフトウェア開発者は、定義したソフトウェア要件からプログラムを設計し、演算プログラムのソースコードであるアプリケーションコード（符号１５）の作成を行う。ここでは、プログラム設計についての記述は省略しているが、例えば、ソフトウェア要件からソフトウェアモデルを作成し、コードを生成してもよいし、ソフトウェア要件からプログラム設計を作成し、手作業でコーディングを行ってもよい。アプリケーションコード１５の生成には、既知の技術および手法を用いることができる。

また、ソフトウェア開発者は、ソフトウェア要件からテストシナリオ（符号１１）を作成する。テストシナリオとは、プログラムに対してテストを行うための、自然言語で記述されたシナリオである。当該シナリオには、利用者による一連の操作と、それに対する結果が記述されており、開発者は、当該シナリオを参照しながらアプリケーションコード１５のテストを行う。

テストシナリオは、ＵＭＬ（Unified Modeling Language：統一モデル言語）によって
記述することもできる。例えば、シーケンスダイアグラム（符号１２）を用いると、利用者の操作をトリガとして、オブジェクト間でどのような呼び出しが行われるかを記述することができる。また、ステートチャート（符号１３）を用いると、利用者の操作に起因したオブジェクトの状態変化を記述することができる。図１では、自然言語で記述されたテストシナリオ（符号１１）、シーケンスダイアグラムによるテストシナリオ（符号１２）、ステートチャートによるテストシナリオ（符号１３）を順番に作成する例を示したが、テストシナリオはいずれかを作成すればよく、全てを作成する必要は無い。

オブザーバコード（符号１４）は、テストシナリオに基づいて作成されるコードであり、演算プログラムがテストシナリオに沿った動作をしているかを監視する監視プログラムのソースコードである。例えば、ＵＭＬによって記述されたステートチャートからオブザーバコードを自動生成する技術として、ＩＢＭ社のRational Rhapsody（登録商標）があ
る。ここでは、ステートチャートからオブザーバコードを自動生成する例を挙げたが、自然言語で記述されたテストシナリオ（符号１１）、またはシーケンスダイアグラムによるテストシナリオ（符号１２）を参照して、手作業でオブザーバコードを作成してもよい。オブザーバコード１４は、前述したテストシナリオごとに作られる。

オブザーバコード１４とアプリケーションコード１５は、互いに独立しているため、オブザーバコードから監視プログラムを生成しても、そのままでは演算プログラムに対して行われる入力操作の監視を行うことができない。そこで、本実施形態では、アスペクト指向プログラミングを利用し、双方のプログラムが互いに情報を交換できるようにしたうえでビルドを行う。アスペクト指向プログラミングについての詳細は後述する。最終的に、ビルドしたモジュールをマイコンや車載コンピュータなどに書き込むことにより、実際の製品が完成する。

<ソフトウェア作成装置>
第一の実施形態に係るソフトウェア作成装置について、詳細に説明する。図２は、本発明に係るソフトウェア作成装置のシステム構成を表した図である。

ソフトウェア要件記憶部２１は、ソフトウェアが満たすべき要求を記述した、ソフトウェア要件（符号１０）を記憶する手段である。ソフトウェア要件は、自然言語で記述してもよいし、ソフトウェアの仕様を記述するためのＬＴＬ（Linear Temporal Logic）や、
ＣＴＬ（Computational Tree Logic）といった仕様記述言語を用いて記述してもよい。
テストシナリオ生成部２２は、ソフトウェア要件に基づいたテストシナリオを作成する手段である。テストシナリオは、前述した通り、自然言語で記述してもよいし、シーケンスダイアグラムやステートチャートによって記述してもよい。テストシナリオをＵＭＬによって記述する場合、Ｅｃｌｉｐｓｅ用に提供されている各種ＵＭＬプラグインを利用することができる。ソフトウェア開発者は、テストシナリオ生成部２２が提供するエディタによってテストシナリオを作成する。

コード生成部２３は、アプリケーションコード１５を作成する手段である。コードは、エディタを利用して手作業でコーディングすることで作成してもよいし、ソフトウェアモデルを作成し、ソフトウェアモデルから自動生成してもよい。ソフトウェアモデルの作成やアプリケーションコードの生成にも、Ｅｃｌｉｐｓｅ用に提供されている各種設計ツールを利用することができる。例えば、MathWorks社のSimulink（登録商標）といった開発
ツールを用いると、ソフトウェアモデルからアプリケーションコードを自動生成することができる。

オブザーバ生成部２４は、テストシナリオ生成部２２で生成したテストシナリオから、オブザーバコードを生成する手段である。前述したように、一つのオブザーバコードは一つのテストシナリオに対応するため、テストシナリオが複数ある場合、複数のオブザーバコードがオブザーバ生成部２４によって生成される。
テストシナリオ生成部２３でステートチャートを作成した場合、前述したRational Rhapsodyにより、Ｊａｖａのオブザーバコードを自動生成することができる。オブザーバコ
ードは、自然言語によるテストシナリオ（符号１１）やシーケンスダイアグラムによるテストシナリオ（符号１２）から手動で作成しても勿論構わない。

コード合成部２５は、オブザーバ生成部２４が生成したオブザーバコードと、コード生
成部２３が生成したアプリケーションコードを合成してビルドする手段である。前述したように、オブザーバコードとアプリケーションコードは互いに独立しているため、そのままでは互いを参照することができず、演算プログラムに対して行われた入力操作を監視することができない。そこで本実施形態では、アスペクト指向プログラミングによって、コード間での入力操作の転送を実現する。

アスペクト指向プログラミングについて説明する。アスペクト指向プログラミング（Aspect Oriented Programming）とは、オブジェクトで分類できない概念をプログラムに織
り込むための技術である。アスペクト指向プログラミングを用いると、例えば、ロギングやアサーション、エラー処理など、クラス分類が難しい機能であって、本来の機能的処理ではない付加的な処理をプログラム中に織り込むことができる。当該処理をアスペクトと呼び、アスペクトを織り込む実行地点をジョインポイントと呼ぶ。すなわち、入力操作をオブザーバコードに渡す処理をアスペクトとし、オブザーバコードおよびアプリケーションコード内にジョインポイントを配置することで、利用者による入力操作を受け渡すことができる。このように、ソフトウェア開発者は、アスペクトを作成し、ジョインポイントを指定するだけで、既に作成されているコードに手を加えることなく機能を追加することができる。

アスペクト指向言語の代表例として、ＡｓｐｅｃｔＪがある。ＡｓｐｅｃｔＪは、Ｊａｖａ言語に対してアスペクト指向プログラミングを実現するための仕様が追加された言語である。コード合成部２５は、ＡｓｐｅｃｔＪを用いて、アプリケーションコードとオブザーバコードを連結する。具体的には、入力操作を受け渡すコードをアスペクトとして作成し、アプリケーションコード内およびオブザーバコード内の、入力操作を受け渡したい部分にジョイントポイントを定義する。これにより、演算プログラムに対する入力操作を監視プログラムが取得することができるようになる。コードの合成は、Ｅｃｌｉｐｓｅ用に提供されているＡｓｐｅｃｔＪプラグインを用いて行う。

図３は、第一の実施形態に係るソフトウェア作成装置によって生成されたプログラムの構成を表す図である。なお、実施形態の説明では、アプリケーションコードから生成された演算プログラムを監視対象プログラム、オブザーバコードから生成された監視プログラムをオブザーバと称する。

コード合成部２５によって、アプリケーションコードとオブザーバコードがビルドされ、実行プログラム３０が生成される。実行プログラム３０には、アプリケーションコードに対応するプログラムである監視対象プログラム３２と、各オブザーバコードに対応するプログラムである複数のオブザーバ３１Ａ，３１Ｂ，３１Ｃ…が含まれる。監視対象プログラムに対して行った入力操作は、各オブザーバにも略同時に入力される。なお、監視対象プログラムと各オブザーバは、同時に実行するという条件を満たせば、一つのモジュールに格納されていてもよいし、複数のモジュールに分かれていてもよい。また、マスタオブザーバ３１Ｍは、前記複数のオブザーバの状態をチェックするためのプログラムである。マスタオブザーバ３１Ｍは、アプリケーションに依存しない共通のプログラムとしてオブザーバ生成部２４に記憶され、コード合成部２５にて同時にビルドされる。図３に示した符号３１の範囲が、本発明における監視プログラムである。マスタオブザーバの動作については後述する。

生成された実行プログラム３０は、コード書込部２６にて、実環境で動作するコンピュータが有する記憶装置（ＲＯＭ）に書き込まれる。実環境で動作するコンピュータとは、例えば自動車に搭載される車載コンピュータ（ＥＣＵ）などである。

図４は、第一の実施形態に係るソフトウェア開発手順を表したフロー図である。ソフト
ウェア開発者は、コード生成部２３にて、ソフトウェア要件からアプリケーションコードを生成し（Ｓ１１）、また、テストシナリオ生成部２２にて、ソフトウェア要件からテストシナリオを設計する（Ｓ１２）。ステップＳ１１とステップＳ１２の手順は、どちらかを先に行ってもよいし、並列して行ってもよい。
そして、オブザーバ生成部２４にて、テストシナリオからオブザーバコードを生成（Ｓ１３）したのち、コード合成部２５にて、アプリケーションコードとオブザーバコードの双方をビルドする（Ｓ１４）。これにより、実行プログラム３０が得られる。最終的に、コード書込部２６にて、生成された実行プログラム３０を対象のコンピュータに書き込み（Ｓ１５）、ソフトウェア開発が完了する。

<プログラムの監視方法>
次に、コンピュータに書き込まれたプログラムの動作を説明する。本実施形態においては、コンピュータとは、車両に搭載される車載端末である。図５は、実行プログラム３０が実行される車載端末１００のシステム構成図である。
車載端末１００は、演算処理装置１０１および記憶装置１０２を有している。実行プログラム３０は、記憶装置１０２に格納されており、演算処理装置１０１にて実行される。また、利用者は、監視対象プログラム３２に対する入力を、入力装置１０３を通して行うことができる。入力装置１０３は、本実施形態ではタッチパネルであるが、キーボードやポインティングデバイスであってもよい。
また、車載端末１００は、外部との無線通信を行うための通信装置１０４、および情報を記録するためのディスク装置１０５を有している。

監視対象プログラムに対する入力操作が、テストシナリオに沿っているかをオブザーバが判定する方法を、具体的な例で説明する。図６は、各オブザーバが保持しているテストシナリオの例である。また、図７は、利用者の操作による監視プログラムの状態遷移を表した図である。例えば、メインメニューからサブメニュー１に遷移した後に、操作Ａ、操作Ｂ、操作Ｃ、操作Ｄの順番で操作を行うことができる。この一連の操作に該当するテストシナリオは、テストシナリオ１および２である。各テストシナリオには、このように、プログラムのテストを行った際の操作の順序が記録されており、各オブザーバ（３１Ａ，３１Ｂ，３１Ｃ…）は、テストシナリオを一つずつ記憶している。本例では、図６に示したテストシナリオを全て監視するために６個のオブザーバが用いられる。

利用者が現に行っている入力操作が、いずれかのオブザーバが記憶しているテストシナリオに記録された操作と一致している限り、当該操作は、プログラムのテスト段階で動作確認がとれているものであることがわかる。逆に、どのテストシナリオにも一致しない操作が行われた場合は、動作確認がされていない状態、すなわち未検証状態であると判定することができる。

利用者が現に行っている入力操作が、どのテストシナリオに一致しているかを判断するための方法を、オブザーバの活性／非活性という語を用いて説明する。「オブザーバが活性状態にある」とは、利用者が行っている入力操作が、当該オブザーバが有しているテストシナリオと一致している状況にあることを意味する。また、「オブザーバが非活性状態にある」とは、利用者が行っている操作が、当該オブザーバが有しているテストシナリオと一致していない状況にあることを意味する。各オブザーバは、取得した入力操作と、自オブザーバが記憶しているテストシナリオとの比較結果に応じて、自オブザーバの状態（活性状態／非活性状態）を切り替えることができる。

具体的な例を挙げて説明する。テストシナリオは、それぞれ起点となる画面からスタートする。図６の例では、メインメニュー画面が全てのテストシナリオの起点である。すなわち、監視対象プログラムがメインメニューを表示した状態では、全てのテストシナリオ
に該当する状態となり、全てのオブザーバが活性状態となる。
利用者が行った操作は、まず、監視対象プログラムに対して入力される。監視対象プログラムのコードには、入力操作を取得する関数とともにジョインポイントが定義されており、利用者が入力操作を行うごとにアスペクトが実行される。アスペクトには、入力操作を取得してオブザーバへ送信する処理が記述されており、これにより、入力された操作が全てのオブザーバへ送信される。
例えば、「メニュー遷移操作１」が行われると、当該操作が全てのオブザーバへ送信される。この操作は、テストシナリオ１〜３のみに該当する操作であるため、テストシナリオ１〜３に対応するオブザーバのみが活性状態となり、他のオブザーバは非活性状態となる。このように、操作が進むにつれて活性状態のオブザーバが減っていく。そして、再度起点であるメインメニューに戻ると、全てのオブザーバが活性状態に戻る。このように、利用者の操作によって、各オブザーバの活性状態と非活性状態が随時切り替わる。

例えば、メインメニューから以下の操作を順に行った場合の、活性状態にあるオブザーバの一覧は以下の通りである。なお、ここでは説明の便宜上、例示したテストシナリオ１〜６に対応するオブザーバを、それぞれオブザーバ１〜６と称する。
（１）初期状態（メインメニュー）：オブザーバ１，２，３，４，５，６
（２）メニュー遷移操作１：オブザーバ１，２，３
（３）操作Ａ：オブザーバ１，２，３
（４）操作Ｆ：オブザーバ３
（５）操作Ｇ：オブザーバ３
（６）操作Ｚ：オブザーバ１，２，３，４，５，６
本例では、メインメニューが各テストシナリオの起点であるため、操作Ｚを行うことによって、全てのオブザーバが活性状態に戻っている。

本実施形態に係る監視プログラム３１は、オブザーバの活性状態に基づいて、監視対象プログラム３２が検証済みの状態であるか否かを判定することができる。車載端末１００上で動作する監視プログラム３１が行う監視処理を、図８のフローチャートで示す。車載端末１００上で実行プログラム３０が開始されると、図８のフローチャートが開始される。

まず、ステップＳ２１で、利用者が入力操作を行うごとに、全てのオブザーバが当該入力操作を取得する。次に、ステップＳ２２およびＳ２３で、各オブザーバが、ステップＳ２１で取得した操作と、自己が有するテストシナリオとを比較する。この結果、自オブザーバが活性化の対象であった場合、活性状態に切り替え（Ｓ２２）、非活性化の対象であった場合、非活性状態に切り替える（Ｓ２３）。非活性状態となったオブザーバは、マスタオブザーバ３１Ｍに対して非活性化した旨を通知する。

ステップＳ２４は、全てのオブザーバが非活性状態であることを検出するステップである。具体的には、マスタオブザーバ３１Ｍが、活性状態にあるオブザーバの数を計数する。ここで、活性状態にあるオブザーバが一つもなかった場合は、テストシナリオに無い操作が行われていることを意味するため、ステップＳ２５に遷移し、マスタオブザーバ３１Ｍがユーザフェールというイベントを発生させる。ユーザフェールとは、プログラムが未検証状態となったことを通知するイベントである。例えば、車両を制御するシステムがユーザフェール状態となった場合、システムを、運転に必要最低限な構成であるセーフモードに移行することが考えられる。また、比較的安全と考えられる状況であった場合、運転者に対する通知のみを行ってもよい。

ユーザフェールが発生すると、マスタオブザーバ３１Ｍは、異常を通知するための外部プログラムを起動し、当該外部プログラムが、ＬＥＤやＬＣＤなどのディスプレイ（非図
示）を通じて、運転者に異常が発生した旨を通知する。また、ディスク装置１０５に、関連する情報をログとして記録する。記録する情報は、プログラムのメモリダンプや、利用者が行った操作のログなどである。なお、これらのログ情報は、通信装置１０４を通して管理センター２００に送信してもよい。また、異常が発生した旨の通知は、監視対象プログラムに対して行ってもよい。
なお、活性状態にあるオブザーバが一つ以上ある場合は、処理はステップＳ２１へ遷移し、再度入力操作を待つ。

本実施形態によれば、コンピュータ上で実行されるオブザーバが、監視対象プログラムに対する入力を監視することにより、テストされていないパターンの入力操作が利用者によってされたことを検出することができる。これにより、システムがクリティカルな状態になる前に通知することができ、システムの安全性を高めることができる。

なお、第一の実施形態では、オブザーバが全て非活性状態となった場合に、マスタオブザーバがユーザフェールを発生させたが、オブザーバの活性状態をチェックする別のプログラムを設け、全てのオブザーバが非活性状態となった場合、当該プログラムがユーザフェールを発生させてもよい。

また、第一の実施形態では、ユーザフェールが発生した場合、必要な処理を行ったのちに動作を終了しているが、ユーザフェールが発生した後に再度オブザーバが活性化した場合は、回復処理を行ったのちに監視を継続するようにしてもよい。回復処理とは、再度検証済みの状態になったことを外部に通知する処理であってもよいし、システムのモードをセーフモードから通常モードに復帰させる処理などであってもよい。

また、本実施形態では、メインメニューを各テストシナリオの起点とし、画面がメインメニューに遷移した際に全オブザーバの活性化を行っているが、オブザーバ活性化のタイミングは、テストシナリオに応じて任意のタイミングとすることができる。例えば、サブメニューに遷移した際に活性化されるオブザーバがあってもよいし、任意の条件を満たした場合に活性化されるオブザーバがあってもよい。

また、対象とする言語はＪａｖａ以外であってもよい。アスペクト指向のフレームワークが使用できれば、例えばＣ言語やＣ＋＋、ＰＨＰなどであってもよいし、監視対象プログラムに対する入力操作を何らかの方法によってオブザーバに通知することができれば、アスペクト指向プログラミングを使用しなくてもよい。例えば、BTC Embedded Systems AG社による開発ツールであるEmbeddedTesterを使用すれば、Ｃ言語で生成したオブザーバ
およびプログラムを互いに接続し、プログラムの監視を実行することができる。

（第二の実施形態）
第二の実施形態は、監視対象のプログラムと、オブザーバとが独立したハードウェア上にて動作する形態である。図９は、第二の実施形態に係る回路構成を表した図である。
本実施形態では、第一の実施形態と同様に、ソフトウェア作成装置によってプログラムの生成を行うが、以下の点において第一の実施形態と相違する。

具体的には、コード生成部２３およびオブザーバ生成部２４で生成されるコードがＪａｖａではなく、ＡＨＤＬやＶＨＤＬなどのハードウェア記述言語である。また、コード合成部２５でのコードの合成は行われず、監視対象プログラムおよびオブザーバが別個にビルドされる。また、コード書込部２６では、監視対象プログラムおよびオブザーバがそれぞれ集積回路等のデジタル回路に別個に書き込まれる。
ソフトウェアの開発手順は、図４に示したフローチャートと同様である。

図９は、監視対象プログラムが書き込まれた監視対象回路４１と、複数のオブザーバが書き込まれたオブザーバ回路４２との関係を表した図である。監視対象回路４１は、監視対象となるプログラム、すなわち第一の実施形態における監視対象プログラム３２が実行される回路である。また、オブザーバ回路４２は、監視を行うプログラム、すなわち第一の実施形態におけるマスタオブザーバ３１Ｍ、および複数のオブザーバ（３１Ａ，３１Ｂ、３１Ｃ…）が実行される回路である。本実施形態では、オブザーバ回路４２は、ユーザインタフェースから監視対象回路４１に入力される操作信号を、入力信号線を経由して取得し、図８に示した処理を行う。ユーザフェール処理が発生した場合、異常信号線を通して外部への異常通報を行う。

異常通報がなされた場合、システムを制御する回路がこれを取得し、第一の実施形態と同様の対応をとることができる。例えば、利用者に通知を行ってもよいし、システムの一部を制限したモードに移行してもよい。また、該当する回路をシステムから切り離してもよい。

本実施形態によると、コンピュータ上ではなく、集積回路上で動作するプログラムにも、本発明を適用することができる。第一の実施形態が、同一のコンピュータ上で動作するのに対し、本実施形態ではオブザーバを別個の集積回路に書き込んでいるため、監視対象システムが動作する回路と、オブザーバが動作する回路とを分離して設計することができるという利点を有している。

（変形例）
なお、各実施形態の説明は本発明を説明する上での例示であり、本発明は、発明の趣旨を逸脱しない範囲で適宜変更または組み合わせて実施することができる。例えば、複数の実施形態を組み合わせてもよいし、仕様外の動作を検出した場合、第一の実施形態にて例示していない方法によって利用者への通知を行ってもよい。

また、実施形態の説明では、利用者が何らかの入力操作を行うごとにオブザーバの活性化および非活性化を行ったが、テストシナリオと関係のない入力操作についてはステップＳ２１で受け捨てるようにしてもよい。例えば、キーボードからの入力がなされた場合であり、当該入力がテキストボックスに対して行われているものであった場合は、入力確定ボタンが押されるまでステップＳ２１で処理を止め、待機するようにしてもよい。

また、実施形態の説明では、クリックやタップなど、プログラムの状態を遷移させるための単純な入力を入力操作として例示したが、入力操作は、入力値を伴うものであってもよい。例えば、テストシナリオに定義された操作が「１０文字以内で文字列を入力」であって、１１文字以上が入力された場合は、テストシナリオに該当しないものとしてオブザーバを非活性化してもよい。このように、テストシナリオに記録される入力操作は、利用者による操作と関連付いたものであれば、どのようなものが定義されてもよい。

また、本発明は、利用者による入力操作に基づいて検証状態／未検証状態の判定を行うものであるが、外部からの入力データに基づいてテストシナリオとの一致を判定する機能を追加してもよいし、システム内部で発生するデータに基づいてテストシナリオとの一致を判定する機能を追加してもよい。このように、テストシナリオと実際の動作とを比較するものであれば、様々なものに応用することができる。

１０ソフトウェア要件
１１テストシナリオ
１２シーケンスダイアグラム
１３ステートチャート
１４オブザーバコード
１５アプリケーションコード
２１ソフトウェア要件記憶部
２２テストシナリオ生成部
２３オブザーバ生成部
２４ソフトウェアモデル生成部
２５コード生成部
２６コード書込部
１００車載端末
１０１演算処理装置
１０２記憶装置
１０３入力装置
１０４通信装置
１０５ディスク装置
２００管理センター

Claims

入力操作を取得する入力手段と、
前記入力手段が取得した入力操作をもとに演算を行う演算プログラムが実行される第一のプログラム実行手段と、
前記演算プログラムに対する複数のテストシナリオを記憶したテストシナリオ記憶手段と、
前記入力手段が取得した入力操作が、前記記憶された複数のテストシナリオのうち、いずれかと対応するものであるかを判定する監視プログラムが実行される第二のプログラム実行手段と、を有するコンピュータ。
前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含む、
請求項１に記載のコンピュータ。
前記監視プログラムは、前記入力手段から複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定する、
請求項２に記載のコンピュータ。
前記監視プログラムは、前記取得した入力操作が、記憶された複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知する、
請求項１から３のいずれかに記載のコンピュータ。
演算を行う演算プログラムと同時に実行され、前記演算プログラムに対する入力操作を監視する監視プログラムであって、
コンピュータに、
前記演算プログラムに対する入力操作を取得する入力取得ステップと、
前記取得した入力操作が、事前に記憶された、前記演算プログラムに対する複数のテストシナリオのうちいずれかと対応するものであるかを判定する入力判定ステップと、
を実行させる、監視プログラム。
前記記憶された各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含む、
請求項５に記載の監視プログラム。
前記入力取得ステップは、複数の入力操作を取得し、
前記入力判定ステップは、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定する、
請求項６に記載の監視プログラム。
前記入力判定ステップにおいて、前記取得した入力操作が、記憶された複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知するステップを実行する、
請求項５から７のいずれかに記載の監視プログラム。
演算を行う演算プログラムと、前記演算プログラムに対する入力操作を監視する監視プログラムと、
を生成するソフトウェア作成装置であって、
前記演算プログラムのコード入力を受け付ける演算プログラム入力手段と、
モデリング言語によって記述された、前記演算プログラムに対する複数のテストシナリオの入力を受け付けるテストシナリオ入力手段と、
前記演算プログラムを生成する演算プログラム生成手段と、
前記複数のテストシナリオを含み、前記演算プログラムに対する入力操作が、前記複数のテストシナリオのうちいずれかと対応するものであるかを判定する監視プログラムを生成する監視プログラム生成手段と、
前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、
を有し、
前記演算プログラム生成手段は、前記演算プログラムに対し、前記演算プログラムが行う所定の処理をトリガとして、前記演算プログラムに対して行われた入力操作を前記監視プログラムに通知する処理を追加する、
ソフトウェア作成装置。
前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含む、
請求項９に記載のソフトウェア作成装置。
前記監視プログラムは、複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定する、
請求項１０に記載のソフトウェア作成装置。
前記監視プログラムは、前記取得した入力操作が、複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知可能である、
請求項９から１１のいずれかに記載のソフトウェア作成装置。