JPH06175845A - ソフトウェア自己高信頼化方法およびその装置 - Google Patents

Abstract

(57)【要約】 【目的】ソフトウエアが自己を高信頼化するために欠陥
に対して自己改造を行うことができる。 【構成】主処理プログラムの実行内容を動作状態検出手
段１２で検出し、故障が検出されるとこれに対する対策
が対策決定手段１３で決定され、この決定内容に従って
プログラム改造手段１５によりソフトウエアの自己改造
が行われる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、自己改造機能を有す
るソフトウエア自己高信頼化方法およびその装置に関す
る

【０００２】

【従来の技術】ソフトウェアを開発するときには、欠陥
を作りこまないようにし、それでも作り込んでしまった
欠陥は、実際の運用に入る前に検出し除去するという観
点からレビューやテストが実施される。しかしながら、
それでも完全に欠陥を無くす事は困難であり、多くの場
合には欠陥が潜在したまま実際の運用に供される。。

【０００３】そして、実際の運用に入ってからの実際の
使用状況により、開発時には発見できなかった欠陥が顕
在化して故障現象がおこることも多く、試行してから修
正改良の要求が顧客から出てくる場合も多い。実際の使
用状況については要求仕様作成時に可能な限り予測する
が、すべては予測できないことと、対処する方法をソフ
トウェアに作り込む手法が不明確であることにより、実
際の運用に入ってからの信頼性が低下し、多大な保守作
業が必要になってくる。

【０００４】

【発明が解決しようとする課題】ソフトウェアは、交通
機関や電源設備、金融や通信をはじめとした会社システ
ムの基幹をなす分野で使われ、また今後ますます適用さ
れる分野が広がる傾向にある。したがって、その社会的
影響の大きさを配慮すれば、高い品質をもったソフトウ
ェアがより一層強く求められる。従って、高い品質のソ
フトウェアを開発し、高い質で運用し、かつ高品質の保
守を行う必要性が強く出てくる。

【０００５】しかしながら、ソフトウェアが複雑化、大
規模化するにつれて、高い品質のソフトウェアを開発
し、高い質で運用し、かつ高品質の保守を行うのが困難
になっている。

【０００６】実際の使用状況について可能な限り予測し
た対処方法を、ソフトウェアに作り込む手法が不明確で
あるために、実際の運用に入ってからの実際の使用状況
により、開発時には検出除去できなかった欠陥が顕在化
し、故障現象が起こって信頼性が低下する。そして、運
用を継続するために修正改良のための大きな負荷のかか
った保守作業が必要になってくる。

【０００７】

【課題を解決するための手段】本発明は、ソフトウェア
自身に高い品質、高い信頼性をその実行に伴って獲得し
ていくようなメカニズムを組み込んで高信頼化の手段を
与えることにより、より高い品質、高い信頼性のソフト
ウェアを実現するソフトウエア自己高信頼化方法および
装置である。この発明は、ソフトウェアの動作実行中
に、ソフトウェア自身が、主要な処理を行うソフトウェ
ア、プログラム部分の動作を観測する自己観測ステップ
と、

【０００８】ソフトウェア自身が、異常・例外・特異状
態であるような故障状態かどうか、また故障状態であれ
ば程度や種別を調べて、故障の原因や続いて起こる現象
を推測し求める自己診断ステップと、ソフトウェア自身
が、その推測された原因や後続現象に対する対応策を探
索して選択決定する意思決定ステップと、ソフトウェア
自身が、選択決定した対応策にもとづいて動作を変更
し、制御する自己制御ステップと、

【０００９】より大きな動作変更が必要なときには、選
択決定した対応策にもとづいてソフトウェアが自己を改
造する自己改造ステップと、を有するソフトウエア自己
高信頼化方法である。

【００１０】この発明は、自己改造機能を持ったソフト
ウエアを実行し、その結果に応じてプログラムの変数デ
−タ変更等を行う装置であって、前記ソフトウエアは、
情報処理を行う主処理部と、主処理部の動作に関連する
プログラム部と、前記主処理部およびプログラム部の欠
陥を検出する検出部と、検出された欠陥に対する対応策
を決定する決定部と、決定された対応策に従って前記ソ
フトウエアを改造する改造部とを含み、前記ソフトウエ
アを保持する手段と、前記ソフトウエアの内容を実行す
る手段と、を備えたことを特徴とする、ソフトウエア自
己高信頼化装置である。

【００１１】

【作用】前記ソフトウエアの動作状態を検出するための
自己認識機能は、自己観測を実行する自己観測機能と自
己診断を実行する自己診断機能とを含み、自己観測機能
により、ソフトウェアの動作実行中に、ソフトウェア自
身が、主要な処理を行うソフトウェアのプログラム部分
（ここでは以下仕事機構と呼ぶ）の動作を観測する。

【００１２】そしてその観測結果をもとに、自己診断機
能が、異常・例外・特異状態であるような故障状態やこ
れらに接近する危険状態かどうか判定する。正常であれ
ば、そのまま仕事機構による仕事を続ける。一方、危険
状態や故障状態であれば、程度や種別を調べて、故障の
原因や続いて起こる現象を推測し求める。

【００１３】自己意思決定機能では意思決定と自己制御
を行う。意思決定機能では、自己診断結果をもとに、そ
の推測された原因や後続現象に対する対応策を探索して
選択決定する。そして、自己制御機能では、仕事機構に
よる主処理プログラム中で選択決定した対応策にもとづ
いて動作を変更し、意思決定にそって制御する。より大
きな動作変更が必要なときには、自己改造機能が選択決
定した対応策にもとづいて自己改造プログラムによりソ
フトウェアが自己を改造する。

【００１４】また、こうしたそれぞれの機能の動きを自
己表現機能により、必要に応じてソフトウェアの外部に
いるユーザ（開発者やオペレータ）に例えば表示手段を
用いて知らせる。

【００１５】さらに、必要に応じて現象、診断、対応
策、結果を組にして、事例データベースに記録してお
く。これにより、事例が増えれば、それらを参照して意
思決定を行うようにもできる。

【００１６】

【実施例】以下、この発明の一実施例について図面を参
照して説明する。

【００１７】図１はこの一実施例に於ける自己改造機能
をもつソフトウエアの内容を示す機能ブロック図であ
る。図において、このソフトウエアの仕事機構である主
処理プログラム実行、制御手段１１は被検プログラム部
であり、その動作状態は動作状態検出手段１２によって
常時監視されている。この監視項目としては、主処理プ
ログラム実行、すなわちソフトウエアの動作実行中に、
制御手段１１が異常、例外または特異状態であるような
故障状態であるか否かの自己観測、および故障状態であ
ればその程度や種別を調べて、故障の原因やつずいて起
るであろう現象を推測する自己診断、等の項目を含む。
動作状態検出手段１２の出力は、その推測された原因や
後続現象に対する対応策を探索して選択、決定する対策
決定手段１３に供給されるとともに、検出の内容は表示
手段１４に送って表示される。

【００１８】対策決定手段１３により決定される対策に
は、検出された故障の内容に応じて大きく分けて２つの
方法がある。ひとつは局所的なプログラムのパラメ−タ
デ−タの変更、たとえば変数デ−タの値の変更であり、
他のひとつは大局的な見地にもとずくソ−スコ−ドの変
更等によるソフトウエアの改造である。この対策決定手
段１３の出力はプログラム改造手段１５に供給され、選
択、決定された対応策にもとずいて動作の変更、制御、
改造が行われる。この対策決定手段１３および改造手段
１５の改造の結果も表示手段１４に表示される。表示手
段１４による表示の内容は例えばオペレ−タ１６に対す
るメッセ−ジである。

【００１９】図１に示した各々の手段１１−１５は全体
として自己改造機能を有するソフトウエアとして構成さ
れる。このソフトウエアは例えば図２に示したメモリの
ようなソフトウエア保持手段２１およびこれに付随した
デ−タベ−ス２２とより構成され、図１に示した各々の
手段の機能はプロセッサのような実行手段２３によって
実現される。このデ−タベ−ス２２には図１の各々の手
段から得られた現象、診断、対応策、結果を組にして、
事例デ−タとして記録しておくこともできる。これによ
り、事例が増えればそれらを参照して自己改造の意思決
定を行うようにもできる。

【００２０】ところで、図１に示した機能を持つソフト
ウエアはたとえば図３に示したプログラムモジュールＭ
１，Ｍ２，Ｍ３，Ｍ４，Ｍｒ，Ｍｄ，Ｍｐ，Ｍｃから構
成される。このうち、モジュ−ルＭ１，Ｍ２，Ｍ３，Ｍ
４は主処理を行う仕事機構であり、Ｍｒは自己認識機構
モジュ−ルであり、Ｍｄは自己意思決定機構モジュ−ル
であり、Ｍｐは自己表現モジュ−ルであり、Ｍｃは改造
機構モジュ−ルである。

【００２１】自己認識機構モジュ−ルＭｒには診断ル−
ルファイルＲｒおよび観測デ−タファイルＳｔが付属し
て設けられ、自己意思決定機構モジュ−ルＭｄには観測
デ−タファイルＳｔおよび意思決定ル−ルファイルＲｄ
が附属して設けられ、自己表現モジュ−ルＭｐには故障
発生事例ファイルＣａが付属して設けられ、改造機構モ
ジュ−ルＭｃには改造指示ファイルＳｃが付属して設け
られる。ここで、各々のモジュールは手続き型プログラ
ムの関数、またはオブジェクト指向プログラムのクラス
・オブジェクトモジュールである。 （１）仕事機構の作成 （１．１）主処理を行う仕事機構（モジュールＭ１，
２，３，４）を作る。 （１．２）処理の中で重要な処理を行うモジュールを複
数箇所決める（ここではＭ２，Ｍ４）。 （１．３）その処理の直前に再開点を設定する（図３の
ｒ１，ｒ２）。 （１．４）再開点を通過して以降の処理で書き換えて更
新してしまうデータはすべて更新前にデータを複製して
保存するようにする。

【００２２】（１．５）実行時に再開点を通過したとき
は、自己認識機構モジュール（Ｍｒ）に通過した再開点
と観測デ−タを知らせるように、観測デ−タセットＳｔ
に書き込むようにしておく。

【００２３】（１．６）それぞれのモジュールでも、プ
ログラムＰの動作状態を表すのに有効なデータも観測デ
ータとして自己認識機構モジュール（Ｍｒ）に知らせる
ようにしておく。 （２）局所的な高信頼化機構の作成 （２．１）モジュールＭ４はサブモジュールｍ０，ｍ
１，ｍ２，ｍ３，ｍ４から構成されている。

【００２４】（２．２）モジュ−ルＭ４は１つの処理を
４つの異なる方法で行えるように準備しており、ｍ１，
ｍ２，ｍ３，ｍ４それぞれの中で実現している。通常は
ｍ１を使って処理をする。ｍ０は、このｍ１の処理が成
功したか失敗したかどうかを観測しており、失敗した場
合には、ｍ１以外のモジュールを代替処理として使い、
再度処理を試みる。つまり、ｍ０はモジュールＭ４内に
局所化された、自己認識、自己意思決定機構のためのサ
ブモジュールとなる。 （３）大局的な高信頼化機構の作成 （３．１）診断ルールファイルＲｒの作成 次のような事項を予測し、それを決められた記述の仕方
で知識を診断ルールとして記述して、診断ルールファイ
ルＲｒを作成する。 （３．１．１）状態ルール プログラムがどんな動作状態になると、どんな故障が起
こっているか、または起こりそうかという知識。 （３．１．２）故障原因ルール 実行中に故障が発生した場合、その原因がどこにあるの
かという知識。 （３．２）動作状態観測データセットの作成 主処理のモジュールから送られてきた観測データを蓄積
しておくためのデータセットＳｔを作成する。 （３．３）観測データや再開点通過の情報が入るとき
に、診断ルールの状態ルールと照合する。主処理で故障
が発生したとの情報が入ったときには、診断ルールの故
障原因ルールと照合する。 （４）自己意思決定機構モジュールの作成 （４．１）意思決定ルールの作成 次のような事項を予め分析しておき、それを決められた
記述の仕方で知識を意思決定ルールとして記述して、意
思決定ルールファイルＲｄを作成する。 （４．１．１）故障影響構造ルール 主処理モジュール同士の相互の故障影響の関係構造と、
再開点の位置についての知識。 （４．１．２）対策ルール ある故障の原因に対して、どんな方法で回復できるかの
知識。

【００２５】（４．２）主処理で故障が発生したとき
に、自己認識機構モジュールＭｒの出す診断結果と、動
作状態観測データセットＳｔを参照して、制御を決定す
る。またプログラムを書き換える必要がある場合には、
その変更指示を決められた記述の仕方でファイルに出力
し、改造指示ファイルＳｃを出力するよう作成する。 （５）自己改造機構モジュールＭｃの作成

【００２６】自己意思決定機構モジュールＭｄで出力さ
れる改造指示ファイルＳｃを読み込み、オンラインでプ
ログラムの変数データの値を更新する（これはプログラ
ムの実行経路を決める変数デ−タの値を更新して実行経
路を切り替えることも含む）か、ソースコードを変更す
るように作成する。

【００２７】通常は、ソースコード自体の書換はプログ
ラムの実行が終了してから、実行するが、ソースコード
が実行時に実行形式に変換されながらプログラムが実行
される、インタプリタ方式の場合には、改造をオンライ
ンで実施することもできる。 （６）自己表現機構モジュールＭｐの作成

【００２８】自己認識機構モジュールＭｒでの故障発生
とその時の動作状態観測データセットや診断結果、自己
意思決定機構による意思決定や故障回復の成否を表示す
る。またこれらを組にして故障発生事例ファイルＣａに
出力するよう作成する。

【００２９】（７）以下、プログラムの実行を図４のフ
ロ−チャ−トを参照しながら説明する。 （７．１）最
初のステップＳ１では主処理プログラムが起動され、次
のステップＳ２では処理が正常であるか否かがチェック
される。通常の実行では、モジュールＭ１，Ｍ２，Ｍ
３，Ｍ４（モジュ−ルＭ４内ではサブモジュ−ルｍ０，
ｍ１による処理）と処理が進んで正常な結果を得る。こ
の場合、ステップＳ３で主処理プログラムが終了したか
がチェックされる。 （７．２）モジュ−ルＭ４内でサブモジュ−ルｍ１によ
る処理が失敗した場合にはステップＳ２で直ちに異常と
はならず次の処理が行われる。 （７．２．１）サブモジュ−ルｍ０がｍ１以外のサブモ
ジュ−ルｍ２，ｍ３，ｍ４をひとつずつ代替に用い、再
度処理を試みる。どれかが成功すれば、実行は正常な結
果を得て、終了する。 （７．３）サブモジュ−ルｍ２−ｍ４による代替処理が
全て失敗した場合にはステップＳ２で異常と決定され、
ステップＳ４に進む。サブモジュ−ルｍ０はソフトウエ
ア全体の動作を観測している自己認識機構モジュールＭ
ｒに、主処理モジュールのＭ４が失敗したことを知らせ
る。

【００３０】（７．４）自己認識機構モジュ−ルＭｒで
は、観測デ−タファイルＳｔに記録されている再開点ｒ
４，ｒ２の通過時の観測デ−タと診断ルールファイルＲ
ｒを参照して、故障状態と故障原因を割り出す。

【００３１】この結果、モジュ−ルＭ２でサンプリング
したデータサイズが小さかったことが失敗の原因である
と診断されたものとする。この診断結果は自己表現機構
モジュ−ルＭｐにより、故障発生と診断結果としてユー
ザにメッセージ表示し、保存する。

【００３２】（７．５）故障内容とその原因が特定され
ると次のステップＳ５に進み、自己意思決定機構モジュ
ールＭｄでは、故障影響構造ル−ルが持つモジュ−ルＭ
２の開始前に再開点ｒ２があるというル−ルと対策ル−
ルにあるサンプルデ−タサイズが少ないなら２倍に増や
すというル−ルをもとに、モジュ−ルＭ２から再度実行
し直すことと、サンプルデータサイズの改造を決定し、
次のステップＳ６に進む。自己表現機構モジュ−ルＭｐ
により、それらのこれから試みようとする対処をユーザ
にメッセージ表示し、記録に保存する。

【００３３】（７．６）改造機構モジュールＭｃによ
り、サンプルデータサイズを書き換える。インタプリタ
形式ならステップＳ７でソースコードをセットし直し、
そうでなければステップＳ８で変数データの値をセット
し直す。 （７．７）書き換えたモジュ−ルＭ２からプログラムを
再開実行する。

【００３４】以上説明したように上記実施例によれば、
仕事機構モジュ−ルＭ１−Ｍ４により主処理を実行する
ときに、モジュ−ルＭ４内にサブモジュ−ルｍ１−ｍ４
を設け、ｍ１による処理が失敗しても他のサブモジュ−
ルｍ２−ｍ４で代替処理を実行し欠陥に対する正常運用
範囲を広くし、モジュ−ルＭ４による処理が失敗しても
モジュ−ルＭｒ，Ｍｄ，Ｍｃによってプログラムの自己
改造を行うことができる。

【００３５】

【発明の効果】以上詳述したようにこの発明によれば以
下のような効果が得られる。 １．局所的な欠陥のリカバリだけでなく、大局的なリカ
バリも可能になる。 ２．実行時の信頼性向上のための設計機構のひな型を与
えることができ、設計者にとっての高信頼化設計方法の
指針となる。

【００３６】３．開発時に完全に欠陥を無くす事は非常
に困難であり、多くの場合には欠陥は潜在しているが、
この欠陥の影響を低減させることができるので、ある程
度補うことができる。

【００３７】４．実際の運用に入ってからの実際の使用
状況により、開発時には発見できなかった欠陥が顕在化
した故障現象に対して、これを抑制し、信頼性をある程
度の水準に保って、あるいは徐々に低下する形態におし
とどめることができる。

【００３８】５．実際に使してみるまで予測できなかっ
た状況や事象に対しても、急激な故障発生を抑制し、信
頼性をある程度の水準に保って、あるいは徐々に低下す
る形態におしとどめることができる。

【００３９】６．軽微な保守作業を不要にする。また大
きな保守作業や試行してから修正改良の要求が顧客から
出てきた場合にも、運用中の実行動作記録を分析するこ
とにより、修正改良の方法についての知識を得ることが
できる。

【図面の簡単な説明】

【図１】この発明のソフトウエアの機能を示すブロック
図。

【図２】この発明の基本構造を示すブロック図。

【図３】この発明の一実施例のプログラム構造を示す
図。

【図４】上記実施例の動作を説明するフロ−チャ−ト。

【符号の説明】

１１…主処理プログラム実行、制御手段、１２…動作状
態検出手段、１３…対策決定手段、１４…表示手段、１
５…プログラム改造手段、２１…ソフトウエア保持手
段、２２…デ−タベ−ス、２３…実行手段、Ｍ１−Ｍ４
…仕事機構モジュ−ル、Ｍｄ…自己意思決定機構モジュ
−ル、Ｍｃ…改造機構モジュ−ル、Ｍｒ…自己認識モジ
ュ−ル、Ｍｐ…自己表現モジュ−ル。

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ソフトウェアが自己の内部に自己を高
   信頼化するための下記のステップを内蔵しているソフト
   ウエア自己高信頼化方法であって、 ソフトウェアの動作実行において、ソフトウェア自身
   が、主要な処理を行うソフトウェア、プログラム部分の
   動作を観測する自己観測ステップと、 ソフトウェア自身が、異常・例外・特異状態であるよう
   な故障状態か否かを検出し、また故障状態であれば程度
   や種別を調べて、故障の原因や続いて起こる現象を推測
   し求める自己診断ステップと、 ソフトウェア自身が、その推測された原因や後続現象に
   対する対応策を探索して選択決定する意思決定ステップ
   と、 ソフトウェア自身が、選択決定した対応策にもとづいて
   動作を変更し、制御する自己制御ステップと、 より大きな動作変更が必要なときには、選択決定した対
   応策にもとづいてソフトウェアが自己を改造する自己改
   造ステップとを具備し、 これらによりソフトウェアが自己の信頼性をソフトウェ
   ア自身で向上させることを特徴とする、ソフトウエア自
   己高信頼化方法。
2. 【請求項２】 自己改造機能を持ったソフトウエア
   を実行する装置であって、前記ソフトウエアは、情報処
   理を行う主処理部と、主処理部の動作に関連するプログ
   ラム部と、前記主処理部およびプログラム部の実行時の
   欠陥を検出する検出部と、検出された欠陥に対する対応
   策を決定する決定部と、決定された対応策に従って前記
   ソフトウエアを改造する改造部とを含み、 前記ソフトウエアを保持する手段と、 前記ソフトウエアの内容を実行する手段と、を備えたこ
   とを特徴とする、ソフトウエア自己高信頼化装置。