JP6659509B2 - 計算機システム、計算機システムによるソフトウェアの送信管理方法、そのためのプログラム、及び、記録媒体 - Google Patents

Description

本発明は、端末に更新ソフトウェアを送信する計算機システム等に関する。

近年では、多くの製品に制御システムが汎用されていることに伴って、機能安全の重要性が叫ばれている。したがって、ソフトウェアの遠隔更新を行うシステムとしてのＯＴＡ(Over The Air)センタについても同じように機能安全が図られなければならない。ＯＴＡセンタとは、被制御製品としてのスマートフォンや自動車等の端末に対し、端末の制御用ソフトウェアを遠隔から更新できるようにしたシステムである。

機能安全規格は1990年代末に欧州を中心に策定されたものであり、国際規格である“IEC 61508”をベースとし、現在では、製品カテゴリごとに独自の機能安全規格が策定されている。

この種の機能安全規格として、“ISO 26262”がある。これは、自動車に搭載されているあらゆるシステムのうち、センサーから、制御装置（ＥＣＵ）、アクチュエータ（モータ）に関して、電気・電子機器等のハードウェア／ソフトウェアを対象としている。

“ISO 26262”は、自動車の要求定義（構想段階）から、開発、生産、保守・運用、廃車に至るまでのライフサイクル全体という広範囲の領域での機能安全を定義しており、自動車メーカ、自動車部品メーカ等のサプライヤはこの規格を順守しなければならない。

機能安全規格の審査のために、ＯＴＡセンタの運営事業者は、端末に配信するソフトウェアの動作実績を利用することができる。これを可能にするシステムとして、例えば、特許文献１で開示されたソフトウェア動作実績管理システムがある。このものは、サーバが端末へ監視ソフトウェアを配信し、サーバが監視ソフトウェアから端末におけるソフトウェアの動作実績を受信するというものである。

特開2008-176722号公報

“ISO 26262”では、ソフトウェア、及び/又は、ハードウェアコンポーネントのモジュールが、“Proven in Use”項によって、定義された安全要求に準拠していることを証明できるようにしている。即ち、ＯＴＡセンタが、端末に、システム更新用のソフトウェアを正常に配信できているという実績を備えていれば、機能安全の審査機関は、この実績を機能安全の要求の評価や審査に流用できる。しかしながら、特許文献１には、サーバ側で、この実績を管理することに何ら配慮がされていない。そこで、本発明は、端末にソフトウェアを送信する際の処理の実績を管理可能な計算機システムを提供することを目的とする。

前記目的を達成するために、本発明は、端末を更新するためのソフトウェアを送信する計算機システムであって、前記ソフトウェアを前記端末に送信するまでの処理を順番に実行する複数のモジュールと、前記複数のモジュール夫々の動作ログを収集するコントローラと、前記コントローラが収集した動作ログを保存するメモリと、を備え、前記コントローラは、前記メモリに保存された動作ログに基づいて、前記複数のモジュールのうち所定のモジュールの動作実績を生成する、ことを特徴とする。

本発明によれば、端末にソフトウェアを送信する際の処理の実績を管理可能な計算機システム等を提供することができる。

ＯＴＡセンタを構成する計算機システムの機能ブロック図である。 計算機システムを構成する処理装置のハードウェア構成の一例である。 計算機システムのモジュールから実績管理モジュールへ送られるテーブル（実行記録の一例）である。 実績管理モジュールが端末から取得する更新記録の例である。 実績管理モジュールが実績ＤＢに保存する実績データの例である。 実績データ処理モジュールへ入力されるモジュールの例である。 実績管理モジュールの動作を示すフローチャートである。 実績データ処理モジュールの動作を示すフローチャートである。 図８の一部の詳細を示すフローチャートである。 図８の他の一部の詳細を示すフローチャートである。 操作モジュールの例（ユーザインタフェース）である。 対象パスの一例である。 対象パスの判定処理（図８の８０２に対応）の詳細を示すフローチャートである。 第２の実施形態における成否判定処理の詳細を示すフローチャートである。

本発明に係る計算機システムの一つの態様としてＯＴＡセンタがあることは既述したとりである。端末の動作、機能を制御するソフトウェアは適宜新しいバージョンに更新されるため、ＯＴＡセンタは、端末に送信される更新ソフトウェアを管理し、そして、更新ソフトウェアを端末へ送信する等、端末のソフトウェアを更新するための処理の大部分を担っている。

ＯＴＡセンタによって、ソフトウェアが更新される端末として、例えば、自動車のエンジンコントロールユニット（ＥＣＵ）があるが、これに限定されるものではなく、例えば、スマートフォン、インテリジェット家電、ガス器具等であってもよい。端末が機能安全規格に準拠したものでなければならないかぎり、ＯＴＡセンタも同じである。

ＯＴＡセンタは、ソフトウェアを端末に送信するまでの処理を順番に実行する複数のモジュールを備える。そして、後述の通り、例えば、端末を更新するための差分ソフトウェア（更新ソフトウェア）を生成するアルゴリズムには複数の方式があるため、同じモジュールでも、複数のタイプが存在する。加えて、チェックサムの算出など、更新ソフトウェアに対する付加処理にも複数の方式があるため、計算機システムは、さらに複数のモジュールを備えることになる。

モジュールとは、計算機システムの機能を発揮する単位である。モジュールには、ハードウェアを主体とするモジュールと、ソフトウェアを主体とするモジュール（機能モジュール）とがある。以下、モジュールといったときは、後者を意味すると考えてよい。モジュールは、プログラムを実行するコントローラによって実現される。モジュールは、プログラムの全部又は一部である。

計算機システムは、既述の“Proven in Use”のために、モジュールの動作実績（稼働実績といってもよい）を、機能安全審査のためのエビデンスとして、生成することができる。動作実績とは、モジュールが正常に動作したか否かの指標であり、例えば、故障率（ＦＩＴ：Failure In Time)がある。さらに、動作実績が機能安全規格の審査にとってエビデンスとして利用できるようにするために、動作実績は、計算機システムが更新ソフトウェアを端末に送信できなかった場合、その原因、例えば、複数のモジュールのうち、どのモジュールにエラーが生じて、ソフトウェアウェア送信までの処理のフローが停止、中断等したかが分かるに足るものであることが望ましい。本発明の計算機システムはこのような動作実績の提供を可能にする。

計算機システムは、ソフトウェアを端末に正しく送信できなかったとき、その原因が端末にあるのか、計算機システムにあるのか、後者の場合、どのモジュールが悪いのかを明らかにすることができる。さらに、計算機システムは、失敗の原因が複数のモジュールの組合せにある場合、これを明らかにすることができる。計算機システム内でソフトウェアウェアを端末に送信するまでの処理のフローは、複数のモジュールのうちどのモジュールを通過したかによって、複数のパスに分かれる。計算機システムは、エラーが発生したパスを明らかにすることもできる。以下、計算機システムについて具体的に説明する。

図１は、ＯＴＡセンタを構成する計算機システム１００の機能ブロック図である。計算機システム１００は、以下に示す通り、複数のモジュールを備えている。符号１０１は更新対象端末に適用される更新情報（ソフトウェア等）であり、１０２は更新対象端末を特定するためのキャンペーン情報である。更新対象端末が自動車のエンジンコントロールユニット（ＥＣＵ）の場合、キャンペーン情報は、自動車メーカ名と車種を含む。更新情報、キャンペーン情報は、自動車メーカのシステムから計算機システム１００に送信される。

更新対象端末に適用されるソフトウェアは、例えば、端末に適用される新バージョンのソフトウェアの全部、或いは、一部である。なお、更新対象端末に適用されるソフトウェアは、旧バージョンとの差分であってもよい。この場合、後述の差分ソフトウェア生成処理は省略してよい。

計算機システム１００は、更新情報の受信（０）、更新処理の管理（１）、差分ソフトウェアの生成（２）、チェックサムの計算（３）、更新対象端末の選択（４）、差分ソフトウェアの送信（５）のステップを順番に進めることによって、端末に更新ソフトウェアを送信する。各ステップは、以下のモジュールによって実行される。

次に、モジュールの詳細について説明する。更新情報の受信（０）ステップにおいて、ソフトウェア保存モジュール１０１Ａは、自動車メーカのシステムから受信したソフトウェアの新バージョンを所定の記憶領域に保存し、キャンペーン情報は管理データベース（管理ＤＢ）１０２Ａに記録される。管理ＤＢ１０２Ａには、複数の端末夫々の送信先アドレス、ＩＤ等、端末の属性情報が登録されている。

更新処理の管理（１）ステップにおいて、更新管理モジュール（Ｍｏｄ−０）１０３は、ソフトウェア保存モジュール１０１Ａから、ソフトウェアの新バージョンが記憶されている記憶領域のアクセスパスの情報を受領し、そして、差分ソフトウェア生成モジュール(Ｍｏｄ−１Ａ,Ｍｏｄ−１Ｂ，・・・)１０４，１０５、・・・の中からどのモジュールを利用するか、さらに、チャックサム計算モジュール(Ｍｏｄ−２Ａ,Ｍｏｄ−２Ｂ，・・・)１０６，１０７・・・の中からどのモジュールを利用するかを、決定、判定、設定、ないしは、選択する。

差分ソフトウェア生成モジュールとサム値計算モジュールとの組合せに複数のパターンがあるために、更新ソフトウェアを端末に送信するまでに、処理のフローに分岐が生じる。更新管理モジュール（Ｍｏｄ−０）１０３は、ソフトウェア（新バージョン）の内容に基づいて、どの差分生成モジュール、どのチェックサム計算モジュールを利用するかを決定してよい。

更新管理モジュール（Ｍｏｄ−０）１０３は、さらに、キャンペーン情報に基づいて管理データベース１０２Ａを参照し、更新ソフトウェアが送信されるべき端末を決定する。更新管理モジュール（Ｍｏｄ−０）１０３はモジュールの決定情報、端末の決定情報、そして、新旧夫々のバージョンのソフトウェアの記憶領域のアクセス情報を差分ソフトウェアの生成（２）ステップに出力する。

差分ソフトウェアの生成（２）ステップにおいて、差分ソフトウェア生成モジュール(Ｍｏｄ−１Ａ,Ｍｏｄ−１Ｂ，・・・)１０４，１０５、・・・は、夫々、ソフトウェアの新バージョンと旧バージョンとを比較して、両者の差分に相当する差分ソフトウェアを生成することができる。差分ソフトウェアが端末を更新するためのソフトウェア（更新ソフトウェア）である。

複数の差分ソフトウェア生成モジュールごとに、差分ソフトウェアを生成するためのアルゴリズムが異なっている。更新管理モジュール（Ｍｏｄ−０）１０３によって決定されたモジュールが差分ソフトウェアを生成する。差分ソフトウェア生成モジュールは、差分ソフトウェアを所定の記憶領域に記録する。差分ソフトウェアを生成したモジュールは、チェックサムの計算（３）ステップに、差分ソフトウェアの記録領域へのアクセス情報と、差分ソフトウェアを送信すべきとして決定された端末の情報とを出力する。

チェックサムの計算（３）のステップにおいて、チェックサム計算モジュール(Ｍｏｄ−２Ａ,Ｍｏｄ−２Ｂ，・・・)１０６，１０７，・・・は、夫々、差分ソフトウェアのチェックサムを計算する。複数のチェックサム計算モジュールごとに、チェックサムを計算するためのアルゴリズムが異なっている。更新管理モジュール（Ｍｏｄ−０）１０３によって決定されたモジュールがチェックサムを計算する。このモジュールは、差分ソフトウェアの記録領域へのアクセス情報とともにチェックサムと端末の決定情報とを端末選択（４）ステップに出力する。

更新対象端末の選択のステップ（４）では、更新対象選択モジュール（Ｍｏｄ−３）１０８は、端末の決定情報の中から、差分ソフトウェアを送信する端末（更新対象端末）を選択して、この選択情報と、差分ソフトウェアへのアクセス情報と、チェックサムとを送信（５）ステップに出力する。更新対象選択モジュール（Ｍｏｄ−３）１０８は、端末の特性等に応じて、複数の送信モジュールの中から最適な送信モジュールから端末に差分ソフトウェアを送信させる。

送信（５）ステップでは、複数の送信モジュールが存在する。送信モジュール(Ｍｏｄ−４Ａ,Ｍｏｄ−４Ｂ，・・・)１０９，１１０・・・は、夫々、配信の経路や、通信規格が異なる。複数の送信モジュールの夫々は、選択された端末に差分ソフトウェアを記憶領域から読み込んで送信する。符号１１１及び１１２は夫々端末である。端末は計算機システム１００から差分ソフトウェアを受け取り、これを自信のシステムにインストールしてソフトウェア更新を行う。差分ソフトウェアを送信するまでのフローは、複数のモジュールのうちどのモジュールを介したか、さらに、どの送信モジュールから端末に送信されたかによって複数のパターンに分岐される。

符号１１３は実績管理モジュールを示す。実績管理モジュール１１３は、計算機システム１００、そして、複数の端末１１１、１１２・・・・、夫々でのソフトウェア更新のための処理の実績を管理するための諸処理を実行する。実績管理モジュール１１３は、既述のモジュールの夫々から、差分ソフトウェアの生成、送信等に係る処理の実行記録（動作ログ）１１６を収集し、そして、端末から更新の結果（更新記録）１１７を収集し、収集したデータから処理の実績データ１１８を抽出、決定、作成等して、実績データベース（実績ＤＢ）１１４に記録する。更新管理モジュール１０３から送信モジュール(１０９、１１０、・・・)に至る夫々のモジュールは処理を終了する都度、実績管理モジュール１１３に、モジュールに於ける処理の実行記録１１６を送る。実績管理モジュール１１３は、複数の端末夫々をポーリングして処理の終了を確認し、端末から更新記録１１７を取得してもよい。

符号１１５は実績データ処理モジュールである。実績データ処理モジュール１１５はモジュールの動作実績を示すために、実績ＤＢ１１４に保存された実績データ１１８に基づいて、モジュールのＦＩＴを計算すること、そして、差分ソフトウェアに係る処理にエラーが生じたモジュール、或いは、エラーを生じさせた、複数のモジュールの組合せを明示することを行う。実績データ処理モジュール１１５へのインストラクションは、操作モジュール１１９から管理者によって与えられる。インストラクションは、実績データ処理モジュール１１５の対象とすべきモジュール、又は、複数のモジュールの組合せを指定することを含む。

図２は、計算機システム１００を構成する処理装置のハードウェア構成の一例を示す。計算機システム１００は、ＣＰＵ２０１、メモリ２０２、ストレージ装置２０３、画面操作インタフェース２０４を備え、ネットワーク２０５によって、外部システムと接続されている。計算機システムは、複数の処理装置２００を組み合わせて構成されてよい。

既述のモジュールは、１つ以上のプログラムを実行するＣＰＵ（コントローラ）２０１として実現される。実績データＤＢ１１４はストレージ装置２０３に存在してよいし、ネットワーク２０５を経由して、計算機システム１００がアクセス可能は外部のストレージ装置に存在してもよい。画面操作インタフェース２０４は、操作モジュール１１９を実現する。

図３は、計算機システム１００のモジュールから実績管理モジュール１１３へ送られるテーブル（実行記録１１６（動作ログ）の一例）である。実行記録１１６は、モジュールの実行ログ、即ち、モジュールにおける処理の履歴であってよい。実行記録１１６は、モジュール名３００と、モジュールが処理を行った時刻３０１、モジュールへの入力データの３０２と、出力データの３０３、処理結果３０４、及び、フローＩＤ３０５と、を含む。入力データ及び出力データとして記載されている符号は、データの記憶領域へのアクセスパスであってよいし、データそのものでもよい。図３に示す項目によって、モジュールの処理の状態を明らかにできる。

図３の実行記録は、更新管理モジュール（Ｍｏｄ−０）１０３のものである。既述の通り、計算機システム１００において、モジュールを通過するデータのフローには分岐があるため、更新管理モジュール１０３は、複数のフローの夫々にフローＩＤを付与することとした。実行記録を出力するモジュールは、処理が正常終了か、失敗したかを判断し、処理結果３０４に「正常」、又は、後者の場合に「エラーコード」を記録する。

処理が失敗したとは、モジュールがデータを出力しない、即ち、データフローがこのモジュールのところで途切れることである。失敗とは、モジュールが適正でないデータを出力した場合を含んでもよい。正常とは、モジュールが適正データを出力してデータフローを継続することである。

図３によれば、更新管理モジュール１０３は、2016/5/25 12:00:00に処理を正常に終了している。モジュール１０３への入力データは/data/data1であり、出力データは/data/data2である。フローＩＤ３０５は、端末へ差分ソフトウェアを配信するまでの処理を一意に示す。

モジュールは、上流のモジュールから入力データとともにフローＩＤを受け取り、出力データをフローＩＤともに下流のモジュールへ渡す。そして、計算機システム１００は同じ差分ソフトウェアを複数の端末へ異なる経路で配信するため、データフローは更新対象選択モジュール１０８以降でさらに分岐する。例えば、送信モジュール１０９が、更新対象選択モジュール１０８からフローＩＤが“Ｆｌｏｗ−０１”のデータを端末に配信した場合、送信モジュール１０９はフローＩＤを自身で分岐させて、“Ｆｌｏｗ−０１−Ａ”のフローＩＤとして実行記録１１６を実績管理モジュール１１３に送信する。

図４は、実績管理モジュール１１３が端末から取得する更新記録１１７の例である。更新記録１１７は、端末名４００、更新を実行した時刻４０１、差分ソフトウェア４０２、処理結果４０３、及び、フローＩＤ１１７と、から構成される。端末での更新が正常終了した場合、処理結果４０３には「正常」と記録されるが、失敗した場合にはエラーコードが記録される。

図４に示す例では、端末ＣＬ−Ａ(１１１)が2016/5/25 12:10:00に、差分ソフトウェアである/data/data6に基づいて、ソフトウェアの更新処理を行ったところ、エラーコード001を実績管理モジュール１１３に返して更新処理が失敗したことを示している。更新処理が失敗されたか否かの決定は端末側で決めてよい。

図５は、実績管理モジュール１１３が実績ＤＢ１１４に保存する実績データ１１８の例である。実績管理モジュール１１３は、実行記録１１６と更新記録１１７とに基づいて、実績データ１１８を作成する。実績データ１１８は、実行記録リスト５０１と、更新記録１１７と、を備える。実行記録リスト５０１は、同一フローＩＤのデータフローに係わる複数のモジュール夫々の実行記録の一覧である。実績データ１１８は、フローＩＤ（Ｆｌｏｗ−０１）によって、実行記録１１６と差分ソフトウェアが送信された端末からの更新記録１１７とを対応させている。

実行記録１１６と更新記録１１７の対応付けについては、図７にて後述する。なお、フローＩＤ５００は端末から取得した更新記録１１７に含まれるフローＩＤ４０４（図４）と同じものであり、実績管理モジュール１１３が端末での更新処理１回に対し１つのフローＩＤを付与する。実行記録リスト５０１は、実行記録１１６と同様に、処理を行った各モジュールのモジュール名５０２、時刻５０３、入力データ５０４、出力データ５０５、処理結果５０６、そして、フローＩＤ５０７とからなる。

実績データ１１８は、各端末での更新処理の１回に対応するため、更新記録１１７においては、端末の記録は１つである。端末へ差分ソフトウェアを配信できなかった場合、実績データ１１８に更新記録１１７は含まれない。実績データ１１８は、端末ごと、そして、端末の更新ごとに存在する。

図５は、更新管理モジュールＭｏｄ−０（１０３)が2016/5/25 12:00:00に処理を行い、入力データ/data/data1を処理して/data/data2を正常に出力し、次に、モジュール差分ソフトウェア生成モジュールＭｏｄ−１Ａ(１０４)が2016/5/25
12:01:01に更新管理モジュールＭｏｄ−０(１０３)から受け取った入力データ/data/data2を正常に処理して/data/data3を出力し、それをチェックサム計算モジュールＭｏｄ−２Ｂ(１０７)が2016/5/25
12:02:02に正常に処理して/data/data4(チェックサム付き差分ソフト)を出力することを示している。

図５は、さらに、送信モジュールＭｏｄ−３（１０８)は2016/5/25 12:03:09に送信対象端末と経路を決定した上で/data/data4を入力として出力データ/data/data5を出力し、送信モジュールＭｏｄ−４Ａ(１０９)は2016/5/25 12:04:03に受け取った/data/data5を端末送信用に/data/data6へと変換して、端末(１１１)へと送信したことを示している。

複数のモジュール夫々で処理は全て正常に終了したため、処理結果５０６には全て「正常」が記録されている。モジュールＭｏｄ−０から、モジュールＭｏｄ−３までのフローＩＤはＦｌｏｗ−０１であるものの、送信モジュール１０９、１１０・・・では、フローに分岐があるため、分岐フローＩＤ“Ｆｌｏｗ−０１−Ａ”が記録されている。差分ソフトウェア/data/data6を受け取った端末Ａ(１１１)は、2016/5/25 12:10:00に更新処理を実行したものの、更新ができなかったため、実行記録の処理結果には「正常」でなくエラーコード“001”が記録されている。

図６は、実績データ処理モジュール１１５へ入力される対象モジュール１２０の例である。図６は、画面表示操作モジュール１１９によって、モジュールの動作実績を管理、取得、確認等するために、モジュール名が実績データ処理モジュール１１５に指定されことを示している。画面表示操作モジュール１１９へのモジュール名の入力は管理者によって行われてよい。管理者は、モジュールでの処理の状況、状況、結果、実績等を確認するために、所定のモジュールを、画面表示操作モジュール１１９を介して、指定、特定、選択することができる。

図７は、実績管理モジュール１１３の動作を示すフローチャートである。実績管理モジュール１１３は、計算機システムの夫々のモジュールから、モジュールでの処理が終了される都度、モジュールの実行記録１１６を取得する（７００)。実績管理モジュール１１３は、実行記録１１６に基づいて、計算機システム内での処理が完了して端末まで差分ソフトウェアを配信できたか否かを判定し、これを肯定した場合(７０１：ＹＥＳ)、送信対象端末から更新記録１１７を受信し（７０２）、フローＩＤ(３０５：図３)とフローＩＤ（４０４：図４)の類似性に基づいて、モジュールの実行記録１１６と更新記録１１７とを対応付けて実績データ１１８を生成する（７０３）。実績管理モジュール１１３は、実績データ１１８を実績ＤＢ１１４に保存する(７０４)。

例えば、更新記録１１７のフローＩＤ４０４が「Ｆｌｏｗ−０１−Ａ−Ａ」であった場合、フローＩＤが「Ｆｌｏｗ−０１」、又は、「Ｆｌｏｗ−０１−Ａ」である実行記録１１６をこの更新記録に対応付ける。「Ｆｌｏｗ−０１−Ａ−Ａ」の「Ａ」は、送信モジュールにおける分岐を示し、「Ｆｌｏｗ−０１−Ａ−Ａ」の「Ａ」は、送信対象端末の違いに基づいた分岐を示す。

更新管理モジュール(Ｍｏｄ−０)、差分ソフトウェア生成モジュール（Ｍｏｄ−１Ａ，１Ｂ・・・）、チェックサム計算モジュール（Ｍｏｄ−２Ａ，２Ｂ・・・）までのデータフローの分岐は、枝番（−Ａ,−Ｂ・・・）で区別されるのではなく、データフローの本流が異なるとして、異なったＩＤ“Ｆｌｏｗ−０１, Ｆｌｏｗ−０２・・・”によって区別される。実績データ１１８のフローＩＤ５００（図５）には、更新記録１１７のフローＩＤ４０４が付与される。

実績管理モジュール１１３が、ステップ７０１を否定判定すると、即ち、計算機システム１００内での処理がデータフローの途中で失敗して、差分ソフトウェアの端末への配信まで処理が進まなかった場合、処理が進んだモジュールまでの実行記録１１６から実績データ１１８を生成して（７０５）、これを実績ＤＢ１１４に保存する（７０４）。この結果、実績データ１１８は更新記録１１７を含まない。

ステップ７０１の判定において、実行記録１１６に含まれる、モジュールの処理結果３０４が「正常」でない場合は、実績管理モジュール１１３は、データフローが当該モジュールで中断されたものと判断する。モジュールは、処理の終了が正常であったか、或いは、失敗であったかを自身で判断できる。その他、モジュールから実行記録１１６が所定時間内に送信されない場合には、実績管理モジュール１１３は、当該モジュールでの処理が失敗されたと判断してもよい。

図８は、実績データ処理モジュール１１５の動作を示すフローチャートである。実績データ処理モジュール１１５は、モジュールの実績を評価、判断するための情報、指標等を算出し、これを、操作モジュール１１９の画面（ユーザインタフェース）に出力させる。実績データ処理モジュール１１５は、モジュールの実績を評価する指標としての、処理成功数と処理失敗数（図１１参照）を０に、処理失敗リストを空に夫々初期化する(８００)。

そして、実績データ処理モジュール１１５は、実績ＤＢ１１４に保存されている全ての実績データ１１８(図５)に対してループ処理を実行し(８０１−８０５)、管理ユーザが操作モジュール１１９に入力したモジュール(対象モジュール)１２０のＦＩＴを計算し、さらに、処理失敗時の実績データを画面表示・操作モジュール１１９に表示する（８０６）。

ループ処理では、実績データ処理モジュール１１５は、対象モジュールの名を複数の実績データ１１８夫々と順番に比較し（８０２）、実績データ１１８が対象モジュール名を含むか否かを判定する（８０３）。実績データ処理モジュール１１５は、これを肯定判定すると、対象モジュールの処理が成功したか失敗したかを、対象モジュールの処理結果（５０６：図５）を参照することによって、判定する（８０４）。実績データ処理モジュール１１５が、ステップ８０３を否定判定すると、成否判定(８０４)を飛ばして、次の実績データの処理を繰り返す。

実績データ処理モジュール１１５は、全実績データについて処理を行った後は、処理結果５０６に“失敗”が記録されている対象モジュールの数に基づいて、ＦＩＴを計算し、さらに、処理成功数、処理失敗数、及び、処理失敗リストを後述の図１１のように纏めて表示する(８０６)。処理失敗リストとは、処理が失敗した対象モジュールを含む実績データ１１８の一覧であってよい。

図９は判定処理８０２，８０３(図８)の詳細を示すフローチャートである。計算機システム１００は、複数のモジュールのうち、管理ユーザが望むモジュールについて、処理実績を作成することができる。処理実績を作成することは、統計的処理によって処理失敗数を算出してＦＩＴを計算することを含む。

実績データ処理モジュール１１５は、実績データ１１８に管理ユーザによって指定されたモジュールが含まれるかを、実績データ１１８の実行記録リスト５０１に記録されたモジュール名５０２によってチェックする(９００)。実績データ処理モジュール１１５は、これを肯定判定すると、実績データ１１８を動作実績処理用の対象データであると判定し(９０１)、これを否定判定すると、対象データではないと判定する(９０２)。

図１０は成否判定処理８０４（図８）の処理の詳細を示すフローチャートである。実績データ処理モジュール１１５は、対象モジュールの動作実績(図１１)を生成するために、成否判定処理を実行することは既述した通りである。実績データ処理モジュール１１５は、モジュールが管理ユーザによって選択されると、対象モジュールについて成否判定処理を行うが、モジュールが選択されなくても、定期的に、全てのモジュールを順番に判定するようにしてもよい。

実績データ処理モジュール１１５は、実績データ１１８をレビューすることによって、端末のソフトウェアの更新ができなかったことが、端末に原因があるのか、又は、計算機システムのモジュールに原因があるのか、後者の場合には、対象モジュールに原因があるか否かを判定、評価、識別、決定、判断等することができる。

実績データ処理モジュール１１５は、処理対象である実績データ１１８（９０１）の実行記録リスト５０１のうち、対象モジュールの処理結果５０６、及び、更新記録１１７の処理結果４０３の全てに“正常”が記録されているか否かをチェックする(１００１)。実績データ処理モジュール１１５は、このステップを肯定すると、対象モジュールの処理は成功であり、端末の処理も成功していると判定し、対象モジュールの処理成功数（図１１参照）を加算（１００５）し、処理を終了する。

実績データ処理モジュール１１５は、ステップ１００１を否定判定すると、失敗が端末に起因するのか否かを判定する（１００３）。実績データ処理モジュール１１５は、実績データ１１８の実行記録リスト５０１の処理結果５０６が全て正常であり、及び、更新記録１１７の処理結果４０３にエラーコードが記録されていることを判定すると、ステップ１００３を肯定判定し、端末の更新の失敗は端末に起因しており、対象モジュールの処理が原因ではないとしてステップ１００５に移行する。

実績データ処理モジュール１１５は、実績データ１１８の実行記録リスト５０１の対象モジュールの処理結果に“失敗”が記録されていると、ステップ１００３を否定判定してステップ１００４に移行する。実績データ処理モジュール１１５は、ステップ１００４において、実績データ１１８の実行記録リスト５０１に含まれる対象モジュールに対する入力データ（入力データへのアクセスパス）５０４を確認し、入力データが正常であるか否かを判定する(１００４)。この判定は、入力データを所定の基準、例えば、対象モジュールの設計仕様で想定している入力データ範囲と比較することによって可能である。

実績データ処理モジュール１１５は、ステップ１００４を否定判定すると、入力データに異常がある、即ち、対象モジュールの上流のモジュールに異常があることによって、対象モジュールにおいてデータフローが中断したのであり、対象モジュール自体に失敗の原因はないとして、ステップ１００５に移行する。

実績データ処理モジュール１１５が、対象モジュールへの入力データが正常であると判定(１００４：ＹＥＳ)すると、入力データ５０４から想定される出力データを設計仕様の処理に従う等して計算する(１００６)。実績データ処理モジュール１１５は、出力データ５０５と想定出力データとを比較する(１００７)。実績データ処理モジュール１１５は、出力データ５０５が想定出力データと一致していることを判定すると(１００７：ＹＥＳ)、対象モジュールの処理の成功を確認してステップ(１００５)に移行する。

実績データ処理モジュール１１５は、ステップ１００７を否定判定すると、対象モジュールの処理は失敗と見做して、図１０に示すように、対象モジュールの処理失敗数を加算して表示し(１００８)、対象モジュールを含む実績データを処理失敗リスト表示領域に追加して(１００９)、処理を終了する。

図１１は図１に示す操作モジュール１１９の例（ユーザインタフェース）である。画面操作モジュール１１９は、対象モジュールの入力領域１２００、処理開始ボタン１２０１、処理成功数表示領域１２０２、処理失敗数表示領域１２０３、ＦＩＴ表示領域１２０４、処理失敗リスト表示領域１２０５と、を備える。

管理ユーザは検索対象入力領域１２００へモジュールの識別情報（モジュール名）を入力し、処理開始ボタン１２０１をクリックすることで、実績データ処理モジュール１１５が処理を開始する。そして、実績データ処理モジュール１１５のシーケンス（図８:８０６）によって、対象モジュールの処理成功の累計数を処理成功数表示領域１２０２に、その処理失敗の累計数を処理失敗数表示領域１２０３に、ＦＩＴをＦＩＴ表示領域１２０４に、処理が失敗した対象モジュールのリストを処理失敗リスト表示領域１２０５のそれぞれに表示させる。

ＦＩＴは、対象モジュールの処理成功数（１２０２）と処理失敗数（１２０３）とから計算される。処理失敗リストは、対象モジュールが原因となって計算機システム内でのデータフローが中断、停止、消滅等した実績データの一欄であってもよい。

以上説明したように、既述の計算機システムによれば、計算機システム内の少なくとも一部のモジュールについてＦＩＴ（動作実績）を明らかにすることができる。したがって、管理者はこれをエビデンスとして、計算機システムの機能安全規格のための申請や審査について利用することができる。さらに、計算機システムは端末を更新するための処理が失敗した場合でも、原因となったモジュールを特定することができるので、モジュールを改良できるなど、機能安全規格を取得する上で有効である。さらに、計算機システムは、動作実績を調べたいモジュールを選択することができる。

次に、第２の実施形態について説明する。先の実施形態では、計算機システム１００は、図１１に示すように、対象モジュールのＦＩＴと動作実績を実績データ処理モジュール１１５が生成するようにしていた。第２の実施形態では、計算機システム１００は、データパス、即ち、複数のモジュールの組合せ（パス）の動作実績を生成することができる。例えば、実績データ処理モジュール１１５に、差分生成モジュールＢ（１０５）とチェックサム計算モジュールＢ（１０７）との組合せからなるパスを指定することによって、実績データ処理モジュール１１５は、対象パスのＦＩＴ、即ち、差分生成モジュールＢ（１０５）で差分ソフトを生成し、チェックサム計算モジュールＢ（１０７）でチェックサム計算を行った場合のＦＩＴを求めることができる。

さらに、例えば、Ｍｏｄ−２Ｂ（チェックサム計算モジュール）は、Ｍｏｄ−１Ａ（差分ソフトウェア生成モジュール）で生成した差分ソフトウェアを受信した場合にはエラーを発生させず、Ｍｏｄ−１Ｂ（差分ソフトウェア）で生成した差分ソフトウェアを受信した場合にエラーを発生させる事象が時として起こる。これは、二つのモジュールのアルゴリズムの相性に問題があることが原因である。

このとき、先の実施形態のようにＭｏｄ−２Ｂを対象モジュールとすると、対象モジュール（Ｍｏｄ−２Ｂ）に対して、Ｍｏｄ−１Ａを含む実績データ１１８ばかりでなく、Ｍｏｄ−１Ｂを含む実績データ１１８も、対象モジュール（Ｍｏｄ−２Ｂ）の動作実績の分析対象になるため、多量の実績データとなって、Ｍｏｄ−１ＢとＭｏｄ−２Ｂとの組合せによるエラーを見付け出すのは困難である。

これに対して、対象パス１４００（図１２）を特定して動作実績を分析することによって、計算機システム１００は、分析対象となる実績データの範囲を制限でき、それ故、Ｍｏｄ−１ＢとＭｏｄ−２Ｂとの組合せに起因するエラーを比較的容易に見付け出すことができる。

図１２に対象パス１４００の一例を示す。対象パス１３００は、複数のモジュール名の一覧１２００から構成される。図１２は、モジュールＭｏｄ−０(更新管理モジュール１０３)とモジュールＭｏｄ−１Ｂ(差分生成モジュールモジュールＢ１０５)、モジュールＭｏｄ−２Ｂ(チェックム計算モジュールＢ１０７)、Ｍｏｄ−３（更新対象選択モジュール１０８）、そして、Ｍｏｄ−４Ａ（送信モジュール１０９）の組合せからなるパスによって、差分ソフトウェアの生成から差分ソフトウェアの送信までの一連のフローが構成されることを示している。

第２の実施形態に係る計算機システムのブロック図（図１，２）は、先の実施形態のものと同じである。第２の実施形態では、対象モジュール１２０に代えて、対象パスが操作モジュール１１９に入力できる点が、第１の実施形態とは異なる。第２の実施形態では、第１の実施形態の“対象モジュール”が“対象パス”に置き換えられる。

図１３は、対象パスの判定処理（図８の８０２に対応）の詳細を示すフローチャートである。実績データ処理モジュール１１５は、実績データ１１８に、対象パス１４００、即ち、対象パス１４００の全てのモジュールが含まれているかを、実行記録リスト５０１(図８)のモジュール名５０２によってチェックする（１５００）。実績データ処理モジュール１１５は、これを肯定判定すると、この実績データ１１８が対象データであると判定する（９０１，９０２）。

図１４は、第２の実施形態における成否判定処理８０４（図８）の詳細を示すフローチャートである。実績データ処理モジュール１１５は、対象パスの選択がされると処理を開始する。実績データ処理モジュール１１５は、対象データである実績データ１１８をレビューすることによって、端末のソフトウェアの更新ができなかったことが、端末に原因があるのか、又は、計算機システムの対象パスに原因があるか否かを判定、評価、識別、決定、判断等することができる。

実績データ処理モジュール１１５は、対象データである実績データ１１８の実行記録リスト５０１のうち、対象パスに含まれる複数のモジュールの処理結果５０６、及び、更新記録１１７の処理結果４０３が全てに“正常”が登録されているか否かをチェックする(１００１)。実績データ処理モジュール１１５は、このステップを肯定すると、対象パスの処理は成功であり、端末の処理も成功していると判定し、対象パスの処理成功数（図１１参照）を加算（１４００）して処理を終了する。

実績データ処理モジュール１１５は、ステップ１００１を否定判定すると、失敗が端末に起因するのか否かを判定する（１００３）。実績データ処理モジュール１１５は、対象パスの複数のモジュールの処理結果５０６が全て正常であれば、更新記録１１７の処理結果４０３にエラーコードが記録されていても、対象パスの処理は成功しているとしてステップ１００３を肯定判定し、ステップ１４００に移行する。

実績データ処理モジュール１１５は、対象パスに含まれるモジュールの処理結果に“エラー”が記録されていると、ステップ１００３を否定判定してステップ１４０２に移行する。実績データ処理モジュール１１５は、対象パス１４００に含まれる全てのモジュールに対し、以下のループ処理(１４０２から１４０４)を行う。ループ処理では、それぞれのモジュールに対し、実績データ１１８の実行記録リスト５０１に含まれる入力データ５０４を確認し、入力データが正常であったかを判定する(１００４)。

モジュールに対する入力データに異常があれば(１００４：ＮＯ)、このモジュールには問題がなかったとして次のモジュールのループ処理に移る(１４０４)。モジュールへの入力データが正常であれば（１００４：ＹＥＳ)、入力データに対して想定される出力データを計算(１００６)し、想定出力データと出力データを比較する(１００７)。出力データ５０５が想定出力値と一致した場合には(１００７：ＹＥＳ)、次のモジュールのループ処理に移る(１４０２)。出力データが想定データと一致しなかった場合は(１００７：ＮＯ)、ループ処理を終了した上で対象パスの処理は失敗と見做し、図１１に示すように、対象パスの処理失敗数を加算して表示し（１４０６）、対象パスを含む実績データを処理失敗リスト表示領域に追加する（１００９）。

以上説明した本発明の複数の実施形態は何れも例であって、本発明はこれら実施形態によって限定されない。実施形態に記載された、要件、条件、装置、方法、部品、機能、範囲、構造、構成等に本発明は限定されない。例えば、計算機システムは、計算機センタ、ソフトウェア送信システム、端末更新システム、サーバ、データセンタ等に言い換えられてもよい。端末は、ソフトウェア更新対象装置、対象製品、対象システム等に言い換えられてもよい。

Claims (13)

1. 端末を更新するためのソフトウェアを送信する計算機システムであって、
   前記ソフトウェアを前記端末に送信するまでの処理を順番に実行する複数のモジュールと、
   前記複数のモジュール夫々の動作ログを収集するコントローラと、
   前記コントローラが収集した動作ログを保存するメモリと、
   を備え、
   前記コントローラは、前記メモリに保存された動作ログに基づいて、前記複数のモジュールのうち所定のモジュールの動作実績を生成する、
   計算機システム。
2. 前記コントローラは、前記動作ログとして、前記複数のモジュール夫々の入力データ、出力データ、そして、処理結果を収集する
   請求項１記載の計算機システム。
3. 前記コントローラは、前記端末から前記ソフトウェアに基づく更新の成否を含む更新情報を取得する
   請求項２記載の計算機システム。
4. 前記コントローラは、記複数のモジュール夫々の動作ログと前記更新情報とを対応付けることにより、前記端末の更新にエラーが発生した場合、前記複数のモジュールの少なくとも一つに原因があるか、又は、前記端末に原因があるかを区別できるように、前記動作実績を生成する
   請求項３記載の計算機システム。
5. 前記コントローラは、管理者によって前記複数のモジュールから選択されたモジュールの動作実績を、前記メモリに保存された動作ログに基づいて、生成する、
   請求項１記載の計算機システム。
6. 前記コントローラは、前記ソフトウェアを前記端末に送信するまでの処理を順番に実行した複数のモジュール夫々の動作ログを一欄にして前記メモリに保存する
   請求項１記載の計算機システム。
7. 前記コントローラは、
   前記ソフトウェアを前記端末に送信するまでの処理を順番に実行した複数のモジュール夫々の動作ログに基づいて、処理を失敗したモジュールを判定し、
   当該モジュールを報知する
   請求項１記載の計算機システム。
8. 前記コントローラは、管理者によって前記複数のモジュールから選択されたモジュールの組合せの動作実績を、前記メモリに保存された動作ログに基づいて、生成する、
   請求項１記載の計算機システム。
9. 前記コントローラは、
   前記ソフトウェアを前記端末に送信するまでの処理を順番に実行した複数のモジュール夫々の動作ログに基づいて、処理を失敗したモジュールの組合せを判定し、
   当該モジュールの組合せを報知する
   請求項１記載の計算機システム。
10. 前記コントローラは、前記メモリに保存された動作ログから、前記複数のモジュールのうち所定のモジュールについて、処理の成功数と処理の失敗数とに基づいて、前記動作実績として、故障率を生成する、
    請求項１記載の計算機システム。
11. 計算機システムが端末を更新するためのソフトウェアの送信を管理するソフトウェアの送信管理方法であって、
    前記計算機システムの複数のモジュールが、前記ソフトウェアを前記端末に送信するまでの処理を順番に行い、
    前記計算機システムのコントローラが、
    前記複数のモジュール夫々の動作ログを収集し、
    前記収集した動作ログをメモリに保存し、
    前記メモリに保存された動作ログに基づいて、前記複数のモジュールのうち所定のモジュールの動作実績を生成する、
    送信管理方法。
12. 計算機システムが端末を更新するためのソフトウェアの送信を管理するようにさせるためのプログラムであって、
    前記計算機システムの複数のモジュールに前記ソフトウェアを前記端末に送信するまでの処理を順番に実行させる機能と、
    前記複数のモジュール夫々の動作ログを収集する機能と、
    前記収集した動作ログをメモリに保存する機能と、
    前記メモリに保存された動作ログに基づいて、前記複数のモジュールのうち所定のモジュールの動作実績を生成する機能と、
    をコンピュータに実現させるためのプログラム。
13. 請求項１２記載のプログラムを記録した、コンピュータが読取可能な非一時的記録媒体。
    

Images