JP2018055645A - 計算機システム、計算機システムによるソフトウェアの更新方法、及び、そのためのプログラム - Google Patents

Abstract

【課題】端末の制御システムを更新するために、端末にソフトウェアを送信できれば、端末がソフトウェアによって正しく機能できるようにした計算機システムを提供する。【解決手段】端末のソフトウェアを遠隔から更新できるように構成された計算機システム１０であり、プロセッサは、端末のソフトウェアを更新するための更新ファイルを生成してメモリに保存し、更新ファイルを送信すべき特定端末を決定し、更新ファイルをメモリから読み出して送信モジュールから特定端末に送信し、特定端末から更新ファイルの動作情報を、受信モジュールを介して受信し、動作情報に基づいて、特定端末以外の端末への前記更新ファイルの配信の要否を判定する。【選択図】図１

Description

本発明は計算機システムに係り、例えば、端末のソフトウェアを遠隔から更新するための計算機システムに関する。本発明は、さらに、計算機システムによるソフトウェアの更新方法、及び、そのためのプログラムに関する。

近年では、多くの製品がソフトウェアによって制御されるようなっている。そして、製品のソフトウェアを更新するためのシステムが存在する（例えば、特開2005-349878号公報）。この種のシステムの一つに、ＯＴＡ(Over The Air)センタがあり、これは、車両のエンジンコントロールユニット（ＥＣＵ）や、その他、スマートフォン等、様々な製品や端末の制御システムを無線通信によって遠隔から更新することを可能にしている。

特開2005-349878号公報

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

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

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

自動車の制御用ソフトウェアを更新するＯＴＡセンタ自体も、自動車と同様に、機能安全規格に準拠したものでなければならない。“ISO 26262”では、ソフトウェア、及び/又は、ハードウェアコンポーネントのモジュールが、“Proven in Use”項によって、定義された安全要求に準拠していることを証明できるようにしている。即ち、ＯＴＡセンタが、端末に、システム更新用のソフトウェアを正常に配信できているという実績を備えていれば、機能安全の審査機関は、この実績を機能安全の要求の評価や審査に流用できる。

しかしながら、ＯＴＡセンタによって、更新用ソフトウェアが端末に問題なく適用できたとしても、端末がソフトウェアによって正しく機能できない場合には、ＯＴＡセンタはソフトウェアの更新をやり直さなければならないばかりか、ひいては、実績の評価も影響を受けるおそれがあった。

そこで、本発明は、端末の制御システムを更新するために、端末にソフトウェアを送信できれば、端末がソフトウェアによって正しく機能できるようにした計算機システム、及び、それに関連する発明を提供することを目的とする。

前記目的を達成するために、本願発明は、端末のソフトウェアを遠隔から更新できるように構成された計算機システムであって、プロセッサと、メモリと、送信モジュールと、受信モジュールと、を備え、前記プロセッサは、前記端末のソフトウェアを更新するための更新ファイルを生成して前記メモリに保存し、前記更新ファイルを送信すべき特定端末を決定し、前記更新ファイルを前記メモリから読み出して前記送信モジュールから前記特定端末に送信し、前記特定端末から前記更新ファイルの動作情報を、前記受信モジュールを介して受信し、前記動作情報に基づいて、前記特定端末以外の端末への前記更新ファイルの配信の要否を判定する、ことを特徴とする。本発明は、さらに、計算機システムによるソフトウェアの更新方法、及び、そのためのプログラムを提供する。

本発明によれば、端末の制御システムを更新するために、端末にソフトウェアを送信できれば、端末がソフトウェアによって正しく機能できるようにした計算機システムを提供することができる。

計算機システムのハードウェアブロック図である。計算機システム１０を構成する複数のモジュールのブロック図である。 計算機システムを構成する複数のモジュールのブロック図である。 更新情報の一例に係るテーブルである。 更新用ソフトウェアのメタ情報の一例に係るテーブルである。 管理ＤＢのうち、車種ＩＤとＥＣＵ ＩＤ（エンジンコントロールユニットのＩＤ）との対応テーブルの一例である。 更新情報の累積テーブルの一例である。 更新用ソフトウェアＤＢの一例である。 パッケージ生成モジュールの詳細ブロック図である。 ソフトウェアパッケージのメタ情報の一例に係るテーブルである。 パッケージＤＢに記録された、ソフトウェアパッケージと試験ログのリンクテーブルの一例である。 試験ログ情報テーブルの一例である。 車両データベースの第１のテーブルである。 車両データベースの第２のテーブルである。 車両選択モジュールの詳細ブロック図である。 ソフトウェアパッケージに属性フラグを設定するためのフローチャートである。 車両選択モジュールの動作を示すフローチャートである。 送信モジュールの動作を示すフローチャートである。 抽出モジュールの動作を示すフローチャートである。 第２の実施形態での更新用ソフトウェアのメタ情報のテーブルの一例である。 複数のタグを階層化したツリー構造の一例である。

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

計算機システムによって、ソフトウェアが更新される端末として、例えば、自動車のエンジンコントロールユニット（ＥＣＵ）があるが、これに限定されるものではなく、例えば、スマートフォン、インテリジェット家電、ガス器具等であってもよい。端末は、製品、又は、更新対象と言い換えられてもよい。

計算機システムは、端末を更新するためのソフトウェアを端末に送信するまでの処理を順番に実行する複数のモジュールを備える。モジュールとは、計算機システムの機能を発揮するための単位である。モジュールには、ハードウェアを主体とするモジュールと、ソフトウェアを主体とするモジュール（機能モジュール）とがある。計算機システムのプロセッサはソフトウェアを実行して、機能モジュールを実現する。機能モジュールは、プログラムの全部又は一部である。

計算機システムは、ソフトウェアが端末で正しく動作しなかった場合、端末からの情報、例えば、エラーコードを解析して、ソフトウェアに不具合があることを特定することは可能である。そして、計算機システムは不具合を解消するためのソフトウェアがあれば、これを端末に配信することはできる。しかしながら、ソフトウェアの配信対象が自動車等機能安全規格に準拠することが求められるものである場合、ソフトウェアを広く配信した後にソフトウェアの不具合が発覚することによる影響は大きい。そこで、計算機システムは、ソフトウェアを端末に広く配信する前に、ソフトウェアの動作具合を実際に検証し、事前検証が済んだソフトウェアを端末に配信するようにした。以下に説明する計算機システムは、自動車のＥＣＵの制御用システムを更新するソフトウェアを、自動車の通信モジュールに無線によって配信するように構成されている。

図１に、計算機システム１０のハードウェアブロック図を示す。計算機システム１０は、サーバシステムとして構成されてよく、プロセッサ、又は、コントローラとしてのＣＰＵ１２と、端末、即ち、更新対象としてのＥＣＵのソフトウェアの更新処理を実行するための制御プログラムや制御用データを記録するメモリ１４（非一時的記録媒体）と、各種データ及びデータベースを記録するストレージ装置１６と、を備える。ストレージ装置１６は計算機システムに内蔵されるハードディスク装置等、及び/又は、ネットワーク２０によって計算機システムがアクセス可能な外部記憶装置（データセンタ）等であってよい。プロセッサ１２は、制御プログラムを実行することによって、複数のモジュールを実現して、端末に於けるソフトウェアの更新を可能にする。計算機システム１０は、ユーザ（車両のサプライヤ、ＯＥＭメーカ等）の計算機システム（サーバ計算機、クライアント計算機）とネットワーク２０によって接続されている。計算機システムをサーバシステム、又は、データセンタと呼んでもよい。

図２は、計算機システム１０を構成する複数のモジュールのブロック図である。インターフェース１０４は、計算機システム１０外の計算機から、更新情報１００と、更新用ソフトウェア（ＥＣＵ用ソフトウェア）１０２を取り込む。更新情報は、例えば、ＯＥＭメーカによって計算機システム１０に提供される。更新用ソフトウェアは、例えば、サプライヤから計算機システム１０に提供される。

更新情報１００は、ソフトウェアの更新を管理するための管理情報である。更新情報の一例が図３Ａに示されている。更新情報１００は、更新ＩＤ（１００Ａ）、対象車種（１００Ｂ）と、更新ファイルＩＤ（１００Ｃ）と、更新前バージョン情報（１００Ｄ）と、更新後バージョン情報（１００Ｅ）と、更新ソフトウェアの内容：テキスト文（１００Ｆ）と、含んでいる。更新ファイルは更新用ソフトウェアのファイルである。

更新ＩＤは、ソフトウェアの更新のためのタスクを一意に区別する識別情報である。対象車種は、更新用ソフトウェアが適用される対象としての車種の情報である。更新ファイルＩＤは、更新用ソフトウェア(更新ファイル)を一意に区別する情報である。更新前バージョン情報は、更新用ソフトウェアの一つ前のバージョンの識別情報であり、更新後バージョンは、更新用ソフトウェアの現在のバージョンの識別情報である。

図３Ｂに、更新用ソフトウェア１０２のメタ情報の例を示す。更新用ソフトウェアは、更新ファイルと更新スクリプトから構成され、メタ情報は、更新ファイルＩＤ（１０２Ａ）と、更新用ソフトウェアのバージョン情報（１０２Ｂ）と、更新ファイルの記憶領域へのリンク情報（１０２Ｃ）と、更新スクリプトのリンク情報（１０２Ｄ）と、を含んでいる。

図２において、インターフェース１０４は、更新情報１００を受信すると、更新情報１００を管理データベース（ＤＢ）１０６に累積記録し、更新用ソフトウェア１０２を受信すると、更新用ソフトウェアを更新用ソフトウェアＤＢ１０８に累積記録する。

図４Ａは、管理ＤＢ１０６のうち、車種ＩＤとＥＣＵ ＩＤ（エンジンコントロールユニットのＩＤ）との対応テーブルの一例であり、図４Ｂは、更新情報１００の累積テーブルの一例である。さらに、図５は更新用ソフトウェアＤＢ１０８の一例である。ＤＢ１０８には更新用ソフトウェアの古いバージョンも記録されている。

計算機システム１０は、更新用ソフトウェアに基づいて対象を更新するための更新ファイルを生成する。更新ファイルは、後述の差分ファイルを備えるソフトウェアパッケージとして生成されてよい。パッケージ生成モジュール１１０（図２）は、ソフトウェアパッケージを生成する。図６は、パッケージ生成モジュールの詳細ブロック図である。差分生成モジュール１１０Ａは、更新ＩＤごとに、管理データベース１０６と、更新用ソフトウェアＤＢ１０８とを参照して、更新用ソフトウェアの現在のバージョンと前回のバージョンとを比較し、前者の後者に対する差分を求めて、差分ファイルを生成する。計算機システム１０は差分ファイルを更新対象に適用することによって、対象のソフトウェアを旧バージョンから新バージョンにアップデートすることができる。

合成モジュール１１０Ｂは、管理データベース１０６を参照して、更新ＩＤから対象車種を決定し、対象車種からＥＣＵ ＩＤを求め、これを差分ソフトウェアに付加して、更新対象に配信されるソフトウェアパッケージを生成する。合成モジュール１１０Ｂは、ソフトウェアパッケージをパッケージＤＢ１１４に記録する。計算機システム１０は、差分ファイルを更新対象に配信することによって、送信するデータ量を低減することができる。

図７に、ソフトウェアパッケージ（パッケージ保存ＤＢ１１４）のメタ情報の一例を示す。ソフトウェアパッケージは、パッケージを一意に区別するパッケージＩＤ（１１２Ａ）と、パッケージが配信されるべきＥＣＵ（対象ＥＣＵ）のＩＤ（１１２Ｂ）と、差分ファイルのリンク情報（１１２Ｃ）と、差分スクリプトのリンク情報（１１２Ｄ）と、属性情報１１２Ｅと、を含む。属性情報とは、ソフトウェアパッケージの事前検証や配信等、更新ファイルを管理するための情報であり、フラグによって管理される。フラグの詳細については後述する。

パッケージＤＢ１１４（図２）は、ソフトウェアパッケージと、更新ファイルの事前検証の結果（検証情報）とを関連させて記録する。事前検証とは、更新ソフトウェアを一般車両のＥＣＵ（特定端末以外の端末、即ち、一般端末）に広く配信する前に試験車両のＥＣＵ（特定端末）に送信し、更新ファイルを試験車両において実際に動作させて、更新用ソフトウェアが試験車両で正常に動作するかを試験することである。試験車両からは更新ファイルの動作情報、即ち、動作試験の結果である検証情報が発信され、計算機システム１０はこれを受信して更新ファイルが動作試験に合格したか否かを判定する。動作試験の合否は、計算機システム１０が判定してもよいし、試験車両の制御システムによって判定されてもよい。検証情報は、試験のログ（試験の実施日時、試験結果）を含む。試験は、複数の項目について実施されてよい。試験が、複数の項目について実施されることによって、更新用ソフトウェアの品質がより正しく評価される。

図８に、パッケージＤＢ１１４に記録された、ソフトウェアパッケージと試験ログのリンクテーブルの一例を示す。このテーブルでは、ソフトウェアパッケージＩＤ（１１４Ａ）に対象ＥＣＵのＩＤ（１１４Ｂ）と試験ログの経過１１４Ｃとを対応させている。計算機システム（後述の試験結果抽出モジュール１２６）は、試験車両から試験結果の情報を受信する都度、試験ログＩＤを決めて試験ログ情報テーブル（図９）を生成するとともに、試験結果（１１４Ｄ）を判定してリンクテーブル（図８）に記録する。図８の「起動」、「ブレーキ」、「加速」、「ステアリング」は、試験項目の例である。「１」は、更新ソフトウェアが試験車両において正常に動作したことを示し、「−」は、試験が行われなかったことを示す。なお、更新ソフトウェアが試験車両において正常に動作しなかった場合には、「０」がリンクテーブルに記録される。なお、試験ログは、既述の“Proven in Use”項に対するエビデンスとなり得る。

図９は試験ログ情報テーブルの一例である。このテーブルは、パッケージデータＤＢ１１４に記録されていてよい。このテーブルは、試験ログのＩＤ毎に、試験を行った試験車両のＩＤと、試験開始日時と、試験終了日時と、結果コード、試験対象と、を含んでいる。計算機システム１０は、結果コードから試験結果を判定する。「０００」は、ソフトウェアが正常に動作したことを示す。

計算機システム１０は、さらに、更新対象（車両）の情報を記録した車両ＤＢ１１６（図２）を備える。次に、車両ＤＢ１１６は車両の情報テーブルであり、図１０Ａにその一例として第１のテーブルを示す。このテーブルは、車両ＩＤ毎に、車種、ＥＣＵ ＩＤ、ＥＣＵを動作させるソフトウェアのバージョン、試験車両フラグ（１：試験車両、０：一般車両）、車両の所在地情報と、車両状態フラグ（１：メンテナンス中、２：試験可能、３：試験中）、走行データと、を含んでいる。

走行データには、「ブレーキ頻度」、「高速道路利用頻度」等車両の走行態様が含まる。計算機システム１０（例えば、モジュール１２６）は、車両を車両データベース１１６に登録する際に、車両ＩＤ、車種、ＥＣＵ ＩＤ、試験車両フラグを設定する。計算機システム１０は、車両のソフトウェアを更新する都度、ソフトウェアのバージョンを書き換える。計算機システム１０は車両から受信した情報に基づいて、車両の所在地情報と、走行データと、を更新する。一般車両にとっては、所在地情報と、走行データは必須ではないが、これら情報は、複数の試験車両の中から、ソフトウェアの動作試験に適した試験車両を選択する際に有効である。

図１０Ｂは、車両データベース１１６の第２のテーブルであって、試験車両のＩＤ毎に、試験項目と、試験が実施された日時、又は、試験が実施される日時（スケジュール）が記録されている。試験項目はフラグ（１：起動試験、２：走行試験、３：故障注入試験）によって管理される。試験車両とは、更新用ソフトウェア（ソフトウェアパッケージ）の検証に適した車両、例えば、ソフトウェアの動作を検出するためのシステム（センサ等）を備えた車両である。試験項目毎に試験車両が別であってもよい。

計算機システム１０は、車両選択モジュール１１８（図２）によって、ソフトウェアパッケージを適用すべき車両を選択する。図１１は当該モジュールの詳細図である。パッケージ選択モジュール５００は、パッケージＤＢ１１４に基づいて、ソフトウェアパッケージを選択する。パッケージＤＢ検索モジュール５０２は、選択されたソフトウェアパッケージのＩＤに基づいてソフトウェアパッケージの送信の要否を判定し、車両ＤＢ検索モジュール５０４は、ソフトウェアパッケージの送信が必要との判定結果に基づいて車両ＤＢ１１６を検索して、ソフトウェアパッケージを送信すべき車両を選択し、結果を送信モジュール１２０に送信する。送信モジュール１２０は、選択された車両にソフトウェアパッケージを送信する。車両には既述のとおり一般車両１３０Ａ，１３０Ｂ、試験車両１２４がある。試験車両は、道路上を実際には走行することなくソフトウェアの動作試験を可能とする模擬試験装置１２２、例えば、運転シミュレータの形態を呈するものであってもよい。

車両情報受信モジュール１２８（図２）は、ソフトウェアパッケージが送信された車両からの情報を受信する。受信情報には、模擬試験装置、試験車両から送られた、ソフトウェアの動作試験の結果が含まれる。その他、受信情報には、ソフトウェアパッケージをＥＣＵに正常にインストールできたか否かの情報が含まれてもよい。

抽出モジュール１２６は、車両情報受信モジュール１２８が受信した情報から、ソフトウェアの動作試験の結果を抽出して、これを、パッケージＤＢ１１４と車両ＤＢ１１６とに記録する。

計算機システム１０は、ソフトウェアパッケージについて、一般車両に広く配信してよいか、配信の前に事前検証をすべきか、事前検証の結果、ソフトウェアの動作に不具合が見つかり、修復作業（デバック等）を必要とするか、等を判定して、判定結果に沿った処理を実施する。計算機システム１０は、これらの判定を、ソフトウェアパッケージ（更新ファイル）の属性に基づいて行う。

ソフトウェアパッケージの属性とは、更新ファイルの事前検証に関する情報であり、フラグＦｒ１：事前検証試験の有無（Ｆｒ１＝０：事前検証試験未、Ｆｒ１＝１：事前検証試験実施）、フラグＦｒ２：事前検証試験結果（Ｆｒ２＝０：試験不合格、Ｆｒ２＝１：試験合格）、フラグＦｒ３：一般車両への配信の要否（Ｆｒ３＝０：配信不要、Ｆｒ３＝１:配信要）、フラグＦｒ４：一般車両への配信の有無（Ｆｒ４＝０：配信未、Ｆｒ４＝１:配信済）、フラグＦｒ５：試験車両への配信の要否（Ｆｒ５＝０：配信不要、Ｆｒ５＝１：配信要）、フラグＦｒ６：試験車両への配信の有無（Ｆｒ６＝０：配信未、Ｆｒ６＝１：配信済）を含む。初期状態では、Ｆｒ１←０、 Ｆｒ２←Ｎｕｌｌ、Ｆｒ３←０、Ｆｒ４←０、Ｆｒ５←０、Ｆｒ６←０のように設定されている。

計算機システム１０（例えば、パッケージ生成モジュール１１０）は、パッケージＤＢ１１４を定期的に参照し、複数のソフトウェアパッケージをパッケージＩＤにしたがって順番に以下のように処理する。図１２に、ソフトウェアパッケージに属性フラグを設定するためのフローチャートを示す。パッケージ生成モジュール１１０は、処理対象パッケージＩＤのフラグＦｒ１をチェックする（Ｓ１２００）。フラグＦｒ１＝「０」である場合にはＦｒ１に「１」をリセット（Ｓ１２０６）してリターンする。

フラグＦｒ１＝「１」である場合には、パッケージ生成モジュール１１０は、フラグＦｒ２がＮｕｌｌか否かを判定し（Ｓ１２０２）、これを肯定すると、ソフトウェアパッケージを一般車両に配信する前に、試験車両において更新ソフトウェアの事前検証が必要であるとして、フラグＦｒ５に「１」をセットする（Ｓ１２１０）。

パッケージ生成モジュール１１０は、ステップ１２０２を否定すると、フラグＦｒ２をチェックし（Ｓ１２０４）、Ｆｒ２＝「１」を判定すると、更新用ソフトウェアの事前検証の結果、更新用ソフトウェアが車両のＥＣＵにおいて正常に動作されたとして、一般車両へのソフトウェアパッケージの配信を許容するために、フラグＦｒ３に「１」をセット（Ｓ１２０８）してリターンする。Ｓ１２０４において、フラグＦｒ２＝「０」を判定すると、このステップを行うことなくリターンする。

図１３は、車両選択モジュール１１８の動作を示すフローチャートである。車両選択モジュール１１８は、フラグＦｒ３をチェックし（Ｓ１３００）、そして、フラグＦｒ４をチェックして（Ｓ１３０４）、Ｆｒ３＝「１」、Ｆｒ４＝「０」を判定すると、処理対象パッケージＩＤのＥＣＵ ＩＤに基づいて、ソフトウェアパッケージＤＢを参照して対応車種を特定し、同じ車種として登録されている一般車両を選択する（Ｓ１３０６）。

車両選択モジュール１１８は、Ｓ１３００においてＦｒ３＝「０」を判定すると、Ｓ１３０８に移行してフラグＦｒ５をチェックする（Ｓ１３０８）。Ｆｒ５＝「１」を判定するとＳ１３１０に移行し、フラグＦｒ６をチェックする。

そして、Ｆｒ６＝「０」を判定すると、処理対象パッケージＩＤに対応するＥＣＵ ＩＤに基づいてＤＢ１１４を参照して対応車種を特定し、同じ車種として登録されている試験車両を選択する（Ｓ１３１２）。車両選択モジュール１１８は、試験車両が複数対応する場合には、試験に適している車両を選択する。選択の基準の一つに、例えば、車両の所在置がある。ソフトウェアについて速度試験を行う場合、テストコースや高速道路に近い車両が好ましいし、通常走行試験を行う場合、一般公道にある車両でよい。パッケージＤＢ１１４の走行データも試験車両を選択する上で参考にしてよい。試験項目毎に異なる試験車両が選択されてもよい。

車両選択モジュール１１８は、Ｆｒ４＝「１」（Ｓ１３０４）、Ｆｒ５＝「０」（Ｓ１３０８）、Ｆｒ６＝「１」（Ｓ１３１０）を判定すると、車両を選択することなくリターンする。車両選択モジュール１１８は、選択車両の情報を送信モジュール１２０に伝達する。

図１４は、送信モジュール１２０の動作を示すフローチャートである。送信モジュール１２０は、処理対象パッケージＩＤのフラグＦｒ３をチェックし（Ｓ１４００）、そして、フラグＦｒ４をチェックする（Ｓ１４０２）。送信モジュール１２０は、Ｆｒ３＝「０」、そして、Ｆｒ４＝「０」を判定すると、一般車両が選択されているか否かを判定し（Ｓ１４０４）、これを肯定すると、フラグＦｒ４に「１」を設定して（Ｓ１４０６）、一般車両にソフトウェアパッケージを配信して（Ｓ１４０８）、リターンする。Ｓ１４０４においてＦｒ４＝１を判定し、Ｓ１４０４を否定判定すると、一般車両にソフトウェアパッケージを配信することなくリターンする。

送信モジュール１２０は、Ｓ１４００において、Ｆｒ３＝０を判定すると、Ｓ１４１０に移行し、さらに、フラグＦｒ５をチェックし、Ｆｒ５＝「１」を判定するとＳ１４１２に移行し、Ｆｒ５＝「０」を判定するとリターンする。Ｓ１４１２において、Ｆｒ６をチェックし、Ｆｒ６＝「０」を判定すると、試験車両が選択されているか否かを判定し（Ｓ１４１４）、これを肯定するとＦｒ６に「１」を設定して（Ｓ１４１６）、試験車両にソフトウェアパッケージを送信して（１４０８）、リターンする。送信モジュール１２０は、ステップＳ１４１２において、Ｆｒ６＝１を判定した場合、Ｓ１４１４を否定判定した場合には、Ｓ１４０８を経ることなくリターンする。

図１５は、抽出モジュール１２６の動作を示すフローチャートである。抽出モジュール１２６は、処理対象パッケージＩＤにパッケージＤＢ１１４を参照して、既述の全ての試験項目の全てにおいて更新ファイルの試験が合格していることを判定すると（Ｓ１５００：ＹＥＳ）、Ｆｒ２に「１」を設定し（Ｓ１５０２）、Ｓ１５００を否定判定するとＦｒ２に「０」を設定して（Ｓ１５０４）、リターンする。計算機システム１０は、処理対象パッケージＩＤにＦｒ２＝「０」を確認すると、処理対象パッケージＩＤのソフトウェアについて、修復処理（デバック等）の対策を講じることができる。なお、抽出モジュール１２６は、処理対象パッケージＩＤにパッケージＤＢ１１４を参照して、既述の全ての試験項目の主要な一部のものにおいて更新ファイルの試験が合格していることを判定すると、Ｆｒ２に「１」を設定してもよい。

既述の計算機システムによれば、複数のモジュールが、フラグを参照することによって、更新用ソフトウェアが事前検証されることなく、多数の端末に配信されることを防ぐことができる。したがって、ソフトウェアが端末に適用出来た場合には、端末がソフトウェアによって正しく機能することを保証することができる。さらに、既述の計算機システムによれば、サプライヤ、ＯＥＭメーカ等ユーザと協同してソフトウェアの更新を行うことができる。

次に、本発明の第２の実施形態について説明する。この実施形態が先の実施形態と異な点は次のとおりである。計算機システム１０は、既述の更新用ソフトウェアにトレーサビリティ情報を付加、関連させる等して、システムが更新されるべき対象を特定、管理等することができる。トレーサビリティ情報として、例えば、ソフトウェアＩＤタグ（以下、タグ、と記載する。）がある。図１６は、更新用ソフトウェアのメタ情報のテーブルである。更新用ソフトウェアには、対象車種に代えてタグが付されている。計算機システムは、更新用ソフトウェアの対象への適用をタグによって分類することができる。

複数のタグを、例えば、図１７に示すように階層化することができる。図１７によれば、ＴＡＧ１はＴＡＧ２とＴＡＧ５との上位タグであり、ＴＡＧ２はＴＡＧ３とＴＡＧ４との上位タグである。ＴＡＧ１がＥＣＵ １、ＥＣＵ ２、ＥＣＵ ３、そして、ＥＣＵ ４、に関係し、ＴＡＧ２がＥＣＵ １、ＥＣＵ ２に関係し、ＴＡＧ３がＥＣＵ １に関係し、ＴＡＧ４がＥＣＵ ２に関係し、そして、ＴＡＧ５がＥＣＵ ３、ＥＣＵ ４に関係する等、ＴＡＧと更新対象とを対応付けることによって、計算機システムはソフトウェアの更新を効率的に進めることができる。

例えば、ＴＡＧ１が付された更新ファイルを車両に適用すれば、ＴＡＧ１は最上位のタグであるため、ＴＡＧ２〜ＴＡＧ５が付されたソフトウェアによる更新は必ずしも必要ではない。同じように、ＴＡＧ２は、ＴＡＧ３とＴＡＧ４との上位タグであるため、ＴＡＧ２が付されたソフトウェアによって対象の更新を行えば、ＴＡＧ３、ＴＡＧ４に基づく更新は必ずしも必要とはされない。ＴＡＧの階層化構造、ＴＡＧと更新対象との対応は、管理テーブルの形態で計算機システムのメモリ１４に設定されてよい。この管理テーブルは、サプライヤによって計算機システムに設定されてよい。パッケージ生成モジュール１１０は、ＴＡＧから更新対象を、管理テーブルによって特定して、ソフトウェアパッケージに付加すればよい。

以上の実施の形態の説明等は本発明を限定するものとして理解されてはならない。この実施の形態は適宜変更されてよい。例えば、計算機システムは、試験車両で正常に動作しなかった更新ファイルに配信禁止フラグを設定し、この更新ファイルが修正されて禁止フラグが解除されるまで一般車両への更新ファイルの配信がされないようにしてもよい。計算機システムは試験車両で正常に動作しなかった更新ファイルをメモリから削除してもよい。計算機システムは、事前検証が不要な更新ファイルに試験不要フラグを設定し、同フラグを確認すると更新ファイルを速やかに一般車両に配信してもよい。

本願発明は、端末のソフトウェアを更新するためのセンタに利用可能である。

１０ 計算機システム
１２ プロセッサ
１４ メモリ
１６ ストレージ装置
２０ ネットワーク

Claims (12)

1. 端末のソフトウェアを遠隔から更新できるように構成された計算機システムであって、
   プロセッサと、
   メモリと、
   送信モジュールと、
   受信モジュールと、
   を備え、
   前記プロセッサは、
   前記端末のソフトウェアを更新するための更新ファイルを生成して前記メモリに保存し、
   前記更新ファイルを送信すべき特定端末を決定し、
   前記更新ファイルを前記メモリから読み出して前記送信モジュールから前記特定端末に送信し、
   前記特定端末から前記更新ファイルの動作情報を、前記受信モジュールを介して受信し、そして、
   前記動作情報に基づいて、前記特定端末以外の端末への前記更新ファイルの配信の要否を判定する
   計算機システム。
2. 前記プロセッサは、
   外部の計算機から前記端末に対する更新用ソフトウェアを受信し、
   前記更新用ソフトウェアに基づいて前記更新ファイルを生成し、
   前記動作情報に基づいて、前記更新ファイルが前記特定端末で正しく動作したことを確認した後、前記更新ファイルを前記特定端末以外の端末に配信する
   請求項１記載の計算機システム。
3. 前記プロセッサは、
   前記更新用ソフトウェアの新バージョンの旧バージョンに対する差分を、前記更新ファイルとして生成する
   請求項２記載の計算機システム。
4. 前記プロセッサは、
   前記特定端末から前記更新ファイルの動作試験の結果を前記動作情報として受信する、
   請求項１記載の計算機システム。
5. 前記プロセッサは、
   前記更新ファイルを前記動作試験のログと対応させて前記メモリに記録する、
   請求項４記載の計算機システム。
6. 前記プロセッサは、
   前記特定端末から前記更新ファイルの複数の項目夫々での動作試験の結果を前記動作情報として受信する、
   請求項４記載の計算機システム。
7. 前記メモリは、前記端末の情報テーブルを備え、
   前記プロセッサは、前記情報テーブルを参照して、前記動作試験が可能な複数の端末の中から前記特定端末を選択する、
   請求項３記載の計算機システム。
8. 前記プロセッサは、
   前記更新ファイルの複数の夫々に付されたタグを参照して、前記更新ファイルを前記特定端末以外の端末に配信する、
   請求項１記載の計算機システム。
9. 前記タグとして複数のタグが階層化されて存在し、
   複数のタグと複数の端末とに所定の対応関係が設定されている、
   請求項８記載の計算機システム。
10. 前記端末が車両の制御システムであり、
    前記特定端末が前記更新ファイルの動作試験が可能な試験車両の制御システムであり、
    前記特定端末以外の端末が、前記更新ファイルが配信される複数の一般車両夫々の制御システムである、
    請求項１記載の計算機システム。
11. 計算機システムが端末のソフトウェアを遠隔から更新する、ソフトウェアの更新方法であって、
    前記計算機システムは、
    前記端末のソフトウェアを更新するための更新ファイルを生成して保存し、
    前記更新ファイルを送信すべき特定端末を決定し、
    前記更新ファイルを読み出して前記特定端末に送信し、
    前記特定端末から前記更新ファイルの動作情報を受信し、そして、
    前記動作情報に基づいて、前記特定端末以外の端末への前記更新ファイルの配信の要否を判定する
    ソフトウェアの更新方法。
12. コンピュータに端末のソフトウェアを遠隔から更新させるためのプログラムであって、
    前記端末のソフトウェアを更新するための更新ファイルを生成して保存することと、
    前記更新ファイルを送信すべき特定端末を決定することと、
    前記更新ファイルを読み出して前記特定端末に送信することと、
    前記特定端末から前記更新ファイルの動作情報を受信することと、そして、
    前記動作情報に基づいて、前記特定端末以外の端末への前記更新ファイルの配信の要否を判定することと、
    を前記コンピュータに実現させるためのプログラム。

Images