特許 7737963 モジュール情報管理システム及びモジュール情報管理方法。

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-09-03

(45)【発行日】2025-09-11

(54)【発明の名称】モジュール情報管理システム及びモジュール情報管理方法。

(51)【国際特許分類】

   G06F 8/71 20180101AFI20250904BHJP

   G06F 8/65 20180101ALI20250904BHJP

【ＦＩ】

G06F8/71

G06F8/65

【請求項の数】 2

(21)【出願番号】P 2022108254

(22)【出願日】2022-07-05

(65)【公開番号】P2024007065

(43)【公開日】2024-01-18

【審査請求日】2024-07-30

(73)【特許権者】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000925

【氏名又は名称】弁理士法人信友国際特許事務所

(72)【発明者】

【氏名】高木 豊和

(72)【発明者】

【氏名】梅津 圭佑

(72)【発明者】

【氏名】出野 正樹

(72)【発明者】

【氏名】助川 祐太

(72)【発明者】

【氏名】藪内 達志

【審査官】西間木 祐紀

(56)【参考文献】

【文献】特開２０１５－０４１３５５（ＪＰ，Ａ）

【文献】特表２００７－５２８０６７（ＪＰ，Ａ）

【文献】特開２０１４－０８５７６６（ＪＰ，Ａ）

【文献】特開２０１３－２５０９２３（ＪＰ，Ａ）

【文献】特開２００１－２６５６９２（ＪＰ，Ａ）

【文献】特開２０２１－００５１４８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／７１

Ｇ０６Ｆ ８／６５

(57)【特許請求の範囲】

【請求項1】

特定の機能を実現するモジュール部であって、複数の処理部において共通して使用可能なモジュール部を一種類以上有する複数の処理部と、前記モジュール部の情報を管理する管理部と、を備えるモジュール情報管理システムであって、
前記処理部は、
当該処理部に格納されたすべての前記モジュールのバージョン情報を格納するモジュールバージョン情報格納部と、
前記モジュールバージョン情報格納部から前記モジュール部のバージョン情報を読み出して前記管理部に送信する第１制御部と、を備え、
前記管理部は、複数の前記処理部から送信されたすべての前記モジュール部のバージョン情報を管理するバージョン情報データベースと、前記モジュール部のデータを更新する制御を行う第２制御部と、複数の前記処理部の動作を制御する処理部制御部と、を備え、
前記モジュール部は、自身のバージョン情報を格納するバージョン情報格納部を備え、予め定められた定期的なタイミングにおいて、自身のバージョン情報を前記バージョン情報格納部に格納し、
前記第１制御部は、予め定められた定期的なタイミングにおいて、前記バージョン情報格納部から前記モジュール部のバージョン情報を読み出して前記モジュールバージョン情報格納部に格納し、前記管理部から前記モジュール部のバージョン情報を読み出すバージョンリード指令を受信した場合、前記バージョンリード指令において指定された前記モジュール部のバージョン情報を前記モジュールバージョン情報格納部から読み出して前記管理部に送信し、
前記第２制御部は、前記バージョン情報データベースに格納された前記モジュール部のバージョン情報に基づいて、データを更新すべき前記モジュール部を特定し、特定した前記モジュール部を対象としてデータ書き換え指令を送信し、
前記処理部制御部は、
複数のすべての前記処理部から送信された前記モジュールのバージョン情報を格納する全処理部バージョン情報格納部と、
前記全処理部バージョン情報格納部から前記モジュール部のバージョン情報を読み出して前記管理部に送信する第３制御部と、をさらに備える
モジュール情報管理システム。

【請求項2】

特定の機能を実現するモジュール部であって、複数の処理部において共通して使用可能なモジュール部を一種類以上有する複数の処理部と、前記モジュール部の情報を管理する管理部と、を備えるモジュール情報管理システムによるモジュール情報管理方法であって、
前記処理部は、
当該処理部に格納されたすべての前記モジュールのバージョン情報を格納するモジュールバージョン情報格納部と、
前記モジュールバージョン情報格納部から前記モジュール部のバージョン情報を読み出して前記管理部に送信する第１制御部と、を備え、
前記管理部は、複数の前記処理部から送信されたすべての前記モジュール部のバージョン情報を管理するバージョン情報データベースと、前記モジュール部のデータを更新する制御を行う第２制御部と、複数の前記処理部の動作を制御する処理部制御部と、を備え、
前記モジュール部は、自身のバージョン情報を格納するバージョン情報格納部を備え、
前記モジュール部が、予め定められた定期的なタイミングにおいて、自身のバージョン情報を前記バージョン情報格納部に格納する手順と、
前記第１制御部が、予め定められた定期的なタイミングにおいて、前記バージョン情報格納部から前記モジュール部のバージョン情報を読み出して前記モジュールバージョン情報格納部に格納する手順と、
前記第１制御部が、前記管理部から前記モジュール部のバージョン情報を読み出すバージョンリード指令を受信した場合、前記バージョンリード指令において指定された前記モジュール部のバージョン情報を前記モジュールバージョン情報格納部から読み出して前記管理部に送信する手順と、
前記第２制御部が、前記バージョン情報データベースに格納された前記モジュール部のバージョン情報に基づいて、データを更新すべき前記モジュール部を特定し、特定した前記モジュール部を対象としてデータ書き換え指令を送信する手順と、を含み、
前記処理部制御部は、
複数のすべての前記処理部から送信された前記モジュールのバージョン情報を格納する全処理部バージョン情報格納部と、
前記全処理部バージョン情報格納部から前記モジュール部のバージョン情報を読み出して前記管理部に送信する第３制御部と、をさらに備える
モジュール情報管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モジュール情報管理システム及びモジュール情報管理方法に関する。

【背景技術】

【0002】

近年、特定の機能を実現するモジュールであって、様々な処理部に適用可能な汎用的なモジュールを複数種類組み合わせることによって、エレベーター等の装置を構成する端末、機器等の各処理部を設計することが行われている。処理部をこのように設計することにより、モジュールによって構成されるソフトウェアの移植性、拡張性の向上を図れるためである。そして、このように様々な端末に格納されたソフトウェアの情報を管理する様々な手法が考案されている。

【0003】

例えば、特許文献１には、車両に搭載された機器のトレーサビリティ情報と関連付けられている機器要求仕様に対応する法規ＩＤと、トレーサビリティ情報に含まれている一つ以上のソフトウェアＩＤとを関連づけた情報である認可ソフトウェア照会情報を生成し、認可ソフトウェア照会情報とトレーサビリティ情報とを関連付けた車両トレーサビリティ情報を生成するソフトウェア照会情報管理システムが開示されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０２１－１９６９３３号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、特許文献１に記載の技術では、法規の機能を構成するソフトウェアが、複数のソフトウェアの組み合わせにより構成されるものである場合には、複数のソフトウェアのまとまりに対してソフトウェア照会番号が割り振られる。そして、該ソフトウェア照会番号と法規ＩＤとが対応付けて管理される。つまり、特許文献１に記載の技術においては、複数のソフトウェアを構成する各ソフトウェア単位での情報のトレーサビリティについては考慮されていない。

【0006】

したがって、汎用性を持つモジュールが様々な処理部で使用される形態において、モジュール単位での機能のアップデートや、モジュールにおける不具合の修正などを行う場合、特許文献１に記載の技術では、対象のモジュールがどの処理部において使用されているかを調べることは困難になる。

【0007】

本発明は、上記の状況を考慮してなされたものであり、本発明の目的は、複数の処理部において共通して使用される複数のモジュールの情報を、一括して管理できるようにすることにある。

【課題を解決するための手段】

【0008】

本発明の一態様に係るモジュール情報管理システムは、特定の機能を実現するモジュール部であって、複数の処理部において共通して使用可能なモジュール部を一種類以上有する複数の処理部と、モジュール部の情報を管理する管理部と、を備えるモジュール情報管理システムである。本発明の一態様に係るモジュール情報管理システムの処理部は、当該処理部に格納されたすべてのモジュールのバージョン情報を格納するモジュールバージョン情報格納部と、モジュールバージョン情報格納部からモジュール部のバージョン情報を読み出して管理部に送信する第１制御部と、を備え、管理部は、複数の処理部から送信されたすべてのモジュール部のバージョン情報を管理するバージョン情報データベースと、前記モジュール部のデータを更新する制御を行う第２制御部と、複数の前記処理部の動作を制御する処理部制御部と、を備える。そして、モジュール部は、自身のバージョン情報を格納するバージョン情報格納部を備え、予め定められた定期的なタイミングにおいて、自身のバージョン情報をバージョン情報格納部に格納し、第１制御部は、予め定められた定期的なタイミングにおいて、バージョン情報格納部からモジュール部のバージョン情報を読み出してモジュールバージョン情報格納部に格納し、管理部からモジュール部のバージョン情報を読み出すバージョンリード指令を受信した場合、バージョンリード指令において指定されたモジュール部のバージョン情報をモジュールバージョン情報格納部から読み出して管理部に送信し、第２制御部は、バージョン情報データベースに格納されたモジュール部のバージョン情報に基づいて、データを更新すべきモジュール部を特定し、特定したモジュール部を対象としてデータ書き換え指令を送信し、処理部制御部は、複数のすべての処理部から送信されたモジュールのバージョン情報を格納する全処理部バージョン情報格納部と、全処理部バージョン情報格納部からモジュール部のバージョン情報を読み出して管理部に送信する第３制御部と、をさらに備える。

【発明の効果】

【0009】

本発明の少なくとも一態様によれば、複数の処理部において共通して使用される複数のモジュールの情報を、一括して管理できるようになる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0010】

【図1】本発明の一実施形態に係るモジュール情報管理システムの概略構成例を示す図である。

【図2】本発明の一実施形態に係るホール端末の制御系の構成例を示すブロック図である。

【図3】本発明の一実施形態に係るモジュール情報管理システムを構成するホール端末、号機制御部、全体管理部のハードウェア構成例を示すブロック図である。

【図4】本発明の一実施形態に係るモジュール部内のバージョン情報格納部の構成例を示す図である。

【図5】本発明の一実施形態に係るペリフェラル部内のモジュールバージョン情報一括格納部の構成例を示す図である。

【図6】本発明の一実施形態に係る号機制御部内の全処理部バージョン情報格納部の構成例を示す図である。

【図7】本発明の一実施形態に係る全体管理部内のバージョン情報データベースの構成例を示す図である。

【図8】本発明の一実施形態に係る全体管理部のＲＯＭデータベースの構成例を示す図である。

【図9】本発明の一実施形態に係る全体管理部の制御部によるバージョンリード処理の手順の例を示すフローチャートである。

【図10】本発明の一実施形態に係る号機制御部の制御部によるバージョンリード処理の手順の例を示すフローチャートである。

【図11】本発明の一実施形態に係るホール端末におけるバージョンセット処理・バージョンリード処理の手順の例を示すフローチャートである。

【図12】本発明の一実施形態に係る全体管理部、号機制御部及びホール端末によるＲＯＭデータ書き換え処理の手順の例を示すフローチャートである。

【発明を実施するための形態】

【0011】

以下、本発明を実施するための形態（以下、「実施形態」と称する）の例について、添付図面を参照しながら説明する。本発明は実施形態に限定されるものではなく、実施形態における種々の数値等は例示である。また、本明細書及び図面において、同一の構成要素又は実質的に同一の機能を有する構成要素には同一の符号を付することとし、重複する説明は省略する。

【0012】

＜モジュール情報管理システムの概略構成＞
まず、図１を参照して、本発明の一実施形態に係るモジュール情報管理システムの構成について説明する。図１は、本発明の一実施形態に係るモジュール情報管理システム１００の概略構成例を示す図である。

【0013】

図１に示すように、モジュール情報管理システム１００は、かご部１と、モータ部２と、ホール端末３＿１～３＿ｎ（ｎは２以上の自然数）と、第１号機制御部４＿１～第３号機制御部４＿３と、全体管理部５と、を備える。

【0014】

第１号機制御部４＿１～第３号機制御部４＿３と全体管理部５との間は、公衆インターネット網等よりなるネットワークＮを介して接続される。

【0015】

かご部１は、不図示の建物の昇降路内を昇降するエレベーターの乗りかごである。
モータ部２は、かご部１を昇降させる巻上機を駆動するモータ（いずれも図示略）等により構成される。
ホール端末３＿１～３＿ｎ（処理部の一例）は、エレベーターのホール（図示略）に設けられたホールボタン３１、インジケータ３２（いずれも図２参照）、及び、これらを制御する制御系により構成される端末である。以下の説明において、ホール端末３＿１～３＿ｎを個別に識別する必要がない場合には、これらをホール端末３と総称する。ホール端末３の制御系の構成については、次の図２を参照して詳述する。

【0016】

なお、本実施形態では、ホール端末３がホールボタン３１及びインジケータ３２を含む例を挙げるが、本発明はこれに限定されない。ホール端末３には、スピーカ、照明灯などのその他の端末が含まれてもよい。

【0017】

［号機制御部］
第１号機制御部４＿１は、かご部１、モータ部２、ホール端末３の動作を制御する制御装置である。本実施形態では、第１号機制御部４＿１～第３号機制御部４＿３の３つの号機制御部が設けられる例を挙げるが、本発明はこれに限定されない。号機制御部の数は、２つ以下でもよく、４つ以上であってもよい。以下の説明において、第１号機制御部４＿１～第３号機制御部４＿３を個別に識別する必要がない場合には、これらを号機制御部４（処理部制御部の一例）と総称する。

【0018】

第１号機制御部４＿１は、通信部４１と、モータ制御部４２と、かご制御部４３と、ホール端末制御部４４と、通信部４５と、ＲＯＭ（Read Only Memory）データ格納部４６と、全処理部バージョン情報格納部４７と、制御部４８と、を含む。

【0019】

通信部４１は、かご部１、モータ部２及びホール端末３のそれぞれと間における通信の動作を制御する。
モータ制御部４２は、モータ部２の動作を制御する。
かご制御部４３は、かご部１の不図示のドアの開閉動作、かご部１内に設けられた不図示の各種端末（以下、「かご内端末」とも称する、処理部の一例）の動作等を制御する。かご内端末には、例えば、行先階ボタン、ドアの開閉ボタン、表示装置、スピーカ、照明灯（いずれも図示略）等が含まれる。

【0020】

ホール端末制御部４４は、ホール端末３の動作を制御する。
通信部４５は、全体管理部５との間における通信の動作を制御する。

【0021】

ＲＯＭデータ格納部４６には、号機制御部４が管理する対象の各端末において使用されている各モジュール部３３１（図２参照）のバージョンに関する情報（バージョン情報）、及び、各モジュール部３３１のデータ（プログラム、以下、ＲＯＭデータとも称する）が格納される。モジュール部３３１は、端末におけるＩＯ（Input Output：入出力）機能、ＩＮＤ（Indicate：表示）機能などを実現するモジュールであり、異なる種類の端末において共通で使用可能なように、汎用的な仕様で設計されている。

【0022】

ＲＯＭデータ格納部４６は、例えば２面により構成され、第１面は書き換えＲＯＭデータによる書き換え前の（現在使用中の）ＲＯＭデータの格納用、第２面は、書き換えＲＯＭデータによる書き換え後の新しいバージョンのＲＯＭデータの格納用に用いられる。そして、全体管理部５よりＲＯＭ書き換え指令が送信された場合に、ＲＯＭデータ格納部４６の面を第１面から第２面に切り替える処理が行われる。ＲＯＭデータ格納部４６に格納されるＲＯＭデータの構成については、後述の図６を参照して詳述する。

【0023】

全処理部バージョン情報格納部４７には、ホール端末３やかご内端末、モータ部２を制御するインバータ端末（図示略）などの各処理部が有する各モジュール部のバージョン情報が一括して格納される。全処理部バージョン情報格納部４７の構成については、後述の図６を参照して詳述する。

【0024】

制御部４８（第３制御部の一例）は、号機制御部４を構成する各部の動作を制御する。また、制御部４８は、全体管理部５からバージョンリード指令が送信された場合に、ホール端末３に対してバージョンリード指令を送信する。そして制御部４８は、該指令に基づいてホール端末３から送信された各モジュール部のバージョン情報で、全処理部バージョン情報格納部４７内のバージョン情報を更新する。これにより、全処理部バージョン情報格納部４７内のバージョン情報は最新に保たれる。さらに、制御部４８は、全処理部バージョン情報格納部４７に格納された各モジュール部のバージョン情報を、通信部４５を介して全体管理部５に送信する。制御部４８による処理については、後述の図１０を参照して詳述する。

【0025】

［全体管理部］
全体管理部５（管理部の一例）は、例えば遠隔地に設置された不図示の監視センタ内等に設けられ、ホール端末３やかご内端末などの各処理部が有する各モジュール部のバージョン情報を管理するとともに、該バージョンの更新処理等を行う。また、全体管理部５は、各処理部が有する各モジュール部のバージョン情報に基づいて、モジュール部のＲＯＭデータの書き換え制御等を行う。
全体管理部５は、バージョン情報データベース５１と、ＲＯＭデータベース５２と、制御部５３と、操作部５４と、を含む。

【0026】

バージョン情報データベース５１には、ホール端末３やかご内端末などの処理部が有するすべてのモジュール部のバージョン情報が格納される。バージョン情報データベース５１の構成については、後述の図７を参照して詳述する。
ＲＯＭデータベース５２には、各モジュール部のＲＯＭデータが格納される。ＲＯＭデータベース５２の構成については、後述の図８を参照して詳述する。

【0027】

制御部５３（第２制御部の一例）は、バージョンリード定期処理の実行タイミングの到来時や、操作部５４を介してユーザよりバージョンリード指令又はＲＯＭ書き換え指令が入力された場合などに、バージョンリード処理を行う。

【0028】

バージョンリード定期処理は、各端末が有する各モジュールのバージョン情報を読み取るために定期的に実行される処理であり、例えば、エレベーターのかご部１に人が乗っていない空き時間や、保守の実行時などに定期的に実行される処理である。バージョンリード処理は、各端末が有する各モジュールのバージョン情報を読み取る処理であり、具体的には、号機制御部４にバージョンリード指令を送信し、該指令に基づいて返信されたバージョン情報によって、バージョン情報データベース５１の情報を更新する処理である。このような定期的なタイミングでバージョン情報データベース５１の情報が更新されることにより、バージョン情報データベース５１内のバージョン情報は、最新の情報に保たれる。

【0029】

バージョンリード指令は、各モジュールのバージョン情報を把握したいユーザによって、操作部５４を介して入力される指示である。

【0030】

ＲＯＭ書き換え指令は、アップデート又は不具合の解消等を目的としてモジュールのバージョン更新が行われる場合における、モジュールのＲＯＭデータの書き換えを指示する指令である。ＲＯＭ書き換え指令も、エレベーターのかご部１に人が乗っていない空き時間や、保守の実行時などに送信される。

【0031】

操作部５４は、例えばマウスやキーボード、あるいはタッチセンサなどによって構成され、ユーザによって入力された操作内容に応じた操作信号を生成して制御部５３に出力する。

【0032】

［ホール端末］
次に、図２を参照して、ホール端末３の制御系の構成について説明する。図２は、ホール端末３の制御系の構成例を示すブロック図である。なお、図２には端末（処理部）の一例としてホール端末３を例示したが、かご内端末等の他の端末も、同様の構成を有するものとする。

【0033】

ホール端末３は、ペリフェラル部３３と全体制御部３４と、を含む。
ペリフェラル部３３は、モジュールＡ部３３１Ａと、モジュールＢ部３３１Ｂと、通信部３３２と、モジュールバージョン情報一括格納部３３３と、ＲＯＭデータ格納部３３４と、を含む。

【0034】

モジュールＡ部３３１Ａは、ホールボタン３１の入出力（ＩＯ：Input Output）機能を提供するモジュールであり、モジュールＢ部３３１Ｂは、インジケータ３２の表示（ＩＮＤ：Indicate）機能を提供するモジュールである。モジュールＡ部３３１Ａ及びモジュールＢ部３３１Ｂの制御系の構成は同一であるため、モジュールＡ部３３１Ａのみを例に挙げて説明する。以下の説明において、モジュールＡ部３３１ＡとモジュールＢ部３３１Ｂとを個別に識別する必要がない場合には、これらをモジュール部３３１と総称する。

【0035】

なお、図２には、ホール端末３がホールボタン３１の入出力機能を提供するモジュールＡ部３３１Ａと、インジケータ３２の表示機能を提供するモジュールＢ部３３１Ｂとの２つのモジュールを有する例を挙げるが、本発明はこれに限定されない。ホール端末３が備えるモジュールは、１つ（種類）であってもよく３つ以上であってもよい。

【0036】

モジュール部３３１は、機能部（ＩＯ）３３１１Ａと、パラメータ格納部３３１２Ａと、バージョン情報格納部３３１３Ａと、を含む。

【0037】

機能部（ＩＯ）３３１１Ａは、ホールボタン３１の入出力機能を提供するモジュールの本体である。機能部（ＩＯ）３３１１Ａは、バージョンセット定期処理の実行タイミングの到来時には、自身のバージョンの情報を不図示のメモリから読み出してバージョン情報格納部３３１３Ａに格納（セット）する。バージョンセット定期処理は、最新のバージョンの情報をバージョン情報格納部３３１３Ａに格納するための定期処理であり、空き時間や、保守の実行時などに定期的に実行される処理である。このような定期的なタイミングで実行される処理に基づいて、バージョン情報格納部３３１３Ａの情報が更新されることにより、バージョン情報格納部３３１３Ａ内のバージョン情報は、最新の情報に保たれる。

【0038】

パラメータ格納部３３１２Ａには、機能部（ＩＯ）３３１１ＡがＩＯ機能を提供するにあたって使用する各種パラメータが格納される。

【0039】

バージョン情報格納部３３１３Ａには、機能部（ＩＯ）のモジュール部のバージョンの情報が格納される。つまり、本実施形態においては、一つの端末において複数種類のモジュール部（図２に示す例では、モジュールＡ部３３１Ａ及びモジュールＢ部３３１Ｂ）が使用されている場合にも、複数の各モジュール部３３１のバージョンの情報が、それぞれのモジュール部３３１において個別に管理される。なお、例えば、システムの運用途中に、端末に格納されるモジュール部の種類が変更された場合には、バージョン情報格納部３３１３内で管理されるモジュール部のバージョン情報も、変更後の情報に更新される。

【0040】

以下の説明において、機能部３３１１Ａと３３１１Ｂとを個別に識別する必要がない場合には、これらを機能部３３１１と総称する。また、パラメータ格納部３３１２Ａと３３１２Ｂとを個別に識別する必要がない場合には、これらをパラメータ格納部３３１２と総称し、バージョン情報格納部３３１３Ａと３３１３Ｂとを個別に識別する必要がない場合には、これらをバージョン情報格納部３３１３と総称する。

【0041】

通信部３３２は、全体制御部３４の通信部３４１との間における通信の動作を制御する。
モジュールバージョン情報一括格納部３３３（モジュールバージョン情報格納部の一例）には、モジュールＡ部３３１Ａのバージョン情報、及び、モジュールＢ部３３１Ｂのバージョン情報が格納される。つまり、モジュールバージョン情報一括格納部３３３には、複数のモジュールが有するそれぞれのバージョンの情報が一括して登録される。モジュールバージョン情報一括格納部３３３の構成については、後述の図５を参照して詳述する。

【0042】

ＲＯＭデータ格納部３３４には、モジュールＡ部３３１Ａ及びモジュールＢ部３３１Ｂの各ＲＯＭデータが格納される。ＲＯＭデータ格納部３３４は、号機制御部４のＲＯＭデータ格納部４６と同様に、２面により構成される。書き換えＲＯＭデータは第２面に書き込まれ、号機制御部４からＲＯＭ書き換え指令を受信したタイミングで、ＲＯＭデータ格納部３３４の面が第１面から第２面に切り替えられる。

【0043】

全体制御部３４は、通信部３４１と、制御部３４２と、を含む。
通信部３４１は、号機制御部４との間における通信動作の制御、及び、ペリフェラル部３３の通信部３３２との間における通信動作の制御を行う。

【0044】

制御部３４２（第１制御部の一例）は、バージョンリード定期処理の実行時や、全体管理部５から送信されるバージョンリード指令又はＲＯＭ書き換え指令等の受信時に、モジュールバージョン情報一括格納部３３３から対象のモジュールのバージョン情報を読み出して、通信部３４１を介して号機制御部４に送信する制御を行う。また、制御部３４２は、全体管理部５よりＲＯＭ書き換え指令及びＲＯＭ書き換えデータが送信された場合には、該ＲＯＭ書き換え指令及びＲＯＭ書き換えデータを、モジュールＡ部３３１Ａ及びモジュールＢ部３３１Ｂに送信する。

【0045】

なお、図１及び図２に示した例では、モジュール情報管理システム１００が、複数の号機制御部４、及び、ホール端末３を含む複数の端末を含む例を挙げたが、本発明はこれに限定されない。例えば、エレベーターの号機が１つである場合には、モジュール情報管理システムは、号機制御部４内のＲＯＭデータ格納部４６及び全体処理部バージョン情報格納部４７は備えない構成とされてもよい。この場合、全体管理部５及びホール端末３は、直接情報のやり取りを行うことができる。

【0046】

具体的には、全体管理部５からバージョンリード指令が送信された場合、ホール端末３の制御部３４２は、モジュールバージョン情報一括格納部３３３から読みだした各モジュール部のバージョン情報を、通信部３４１を介して全体管理部５に送信することができる。

【0047】

＜計算機のハードウェア構成例＞
次に、図１に示したモジュール情報管理システム１００の制御系の機能を実現するための各装置のハードウェア構成について、図３を参照して説明する。

【0048】

図３は、モジュール情報管理システム１００を構成するホール端末３、号機制御部４、全体管理部５のハードウェア構成例を示すブロック図である。図３に示す計算機２００は、いわゆるコンピュータとして用いられるハードウェアである。

【0049】

計算機２００は、バスＢにそれぞれ接続されたＣＰＵ（Central Processing Unit）２０１、ＲＯＭ（Read Only Memory）２０２、ＲＡＭ（Random Access Memory）２０３、表示部２０４、操作入力部２０５、不揮発性ストレージ２０６及び通信インターフェース２０７を備える。

【0050】

ＣＰＵ２０１は、本実施形態に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭ２０２から読み出してＲＡＭ２０３に展開して実行する。なお、計算機２００は、ＣＰＵ２０１の代わりに、ＭＰＵ（Micro-Processing Unit）等の処理装置を備えてもよい。ＲＡＭ２０３には、演算処理の途中に発生した変数やパラメータ等が一時的に書き込まれる。

【0051】

全体管理部５の制御部５３、号機制御部４の制御部４８、ホール端末３の全体制御部３４の制御部３４２、モジュール部３３１の機能部３３１１の各機能は、ＣＰＵ２０１がＲＯＭ２０２から該当するプログラムコードを読み出してＲＡＭ２０３に展開して実行することにより実現される。

【0052】

表示部２０４は、例えば、ＬＣＤ（Liquid Crystal Display）等で構成されるモニタであり、計算機２０で行われる処理の結果等を表示する。
操作入力部２０５は、例えば、キーボード、マウス、タッチセンサ等によって構成され、ユーザによる操作に応じた操作信号を生成してＣＰＵ２０１に供給する。全体管理部５の操作部５４の機能は、操作入力部２０５により実現される。

【0053】

なお、表示部２０４と操作入力部２０５とは、タッチパネルとして一体に構成されてもよい。また、計算機２００は、表示部２０４及び操作入力部２０５を備えない構成とされてもよい。

【0054】

不揮発性ストレージ２０６としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フレキシブルディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、不揮発性のメモリカード等を用いることができる。この不揮発性ストレージ２０６には、ＯＳ（Operating System）、各種のパラメータの他に、計算機２００を機能させるためのプログラム等が記録される。なお、プログラムは、ＲＯＭ２０２に格納されてもよい。

【0055】

プログラムは、コンピュータが読取り可能なプログラムコードの形態で格納され、ＣＰＵ２０１は、当該プログラムコードに従った動作を逐次実行する。つまり、ＲＯＭ２０２又は不揮発性ストレージ２０６は、コンピュータによって実行されるプログラムを格納した、コンピュータ読取可能な非一過性の記録媒体の一例として用いられる。

【0056】

全体管理部５のバージョン情報データベース５１、ＲＯＭデータベース５２、号機制御部４のＲＯＭデータ格納部４６、全処理部バージョン情報格納部４７、ホール端末３のモジュールバージョン情報一括格納部３３３、ＲＯＭデータ格納部３３４、モジュール部３３１のパラメータ格納部３３１２、バージョン情報格納部３３１３の各機能は、不揮発性ストレージ２０６又はＲＯＭ２０２によって実現される。

【0057】

通信インターフェース２０７には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、ネットワーク又は通信線を介して外部装置との間で各種のデータを送受信することが可能である。号機制御部４の通信部４５、ホール端末３の全体制御部３４の通信部３４１、ホール端末３のペリフェラル部３３の通信部３３２の各機能は、通信インターフェース２０７によって実現される。

【0058】

＜モジュール部内のバージョン情報格納部の構成＞
次に、図４を参照して、モジュール部３３１内のバージョン情報格納部３３１３の構成について説明する。図４は、モジュール部３３１内のバージョン情報格納部３３１３の構成例を示す図である。図４Ａには、のバージョン情報格納部３３１３Ａの構成例を示し、図４Ｂには、バージョン情報格納部３３１３Ｂの構成例を示す。

【0059】

図４Ａに示すバージョン情報格納部３３１３Ａは、内容フィールドＦ１、アドレスフィールドＦ２、データフィールドＦ３の各フィールドを有する。内容フィールドＦ１には、格納される情報は、モジュールＡ部３３１Ａのバージョン情報及び該バージョンの更新日時であることを示す文字が、項目として格納される。具体的には、「モジュールＡ部のバージョン」及び「モジュールＡ部の更新日時」の文字が格納される。

【0060】

アドレスフィールドＦ２には、モジュールＡ部３３１Ａのバージョン情報及び該バージョンの更新日時の各情報が格納されたアドレスの情報が格納される。
データフィールドＦ３には、バージョン情報のデータ及びバージョンの更新日時を示すデータが格納される。

【0061】

例えば、バージョン情報格納部３３１３Ａの一番目のレコードには、アドレス“Ｈ’００”に、モジュールＡ部３３１Ａのバージョン情報のデータである“３２Ｈ’０００１＿００００”が格納されていることが示されている。また、２番目のレコードには、アドレス“Ｈ’０１”に、バージョンの更新日時を示すデータである“３２Ｈ’２０２２＿０５１３”が格納されていることが示されている。

【0062】

図４Ｂに示すバージョン情報格納部３３１３Ｂも同様に、内容フィールドＦ１１、アドレスフィールドＦ１２、データフィールドＦ１３の各フィールドを有する。これらの各フィールドが持つ意味は図４Ａに示したバージョン情報格納部３３１３Ａにおけるそれらと同一であるため、ここではこれらの説明は省略する。

【0063】

例えば、バージョン情報格納部３３１３Ｂの一番目のレコードには、アドレス“Ｈ’００”に、モジュールＢ部３３１Ｂのバージョン情報のデータである“３２Ｈ’０００２＿００００”が格納されていることが示されている。また、２番目のレコードには、アドレス“Ｈ’０１”に、バージョン情報の更新日時を示すデータである“３２Ｈ’２０２２＿０５１３”が格納されていることが示されている。

【0064】

つまり、ホール端末３はモジュールＡ部３３１Ａ及びモジュールＢ部３３１Ｂの組み合わせによってその機能が実現されるが、本実施形態では、２つのモジュール部の組み合わせの情報ではなく、１つ１つの各モジュール部のバージョン情報が、それぞれのパラメータ格納部３３１２において管理される。

【0065】

＜ペリフェラル部内のモジュールバージョン情報一括格納部の構成＞
次に、図５を参照して、ペリフェラル部３３内のモジュールバージョン情報一括格納部３３３の構成について説明する。図５は、ペリフェラル部３３内のモジュールバージョン情報一括格納部３３３の構成例を示す図である。

【0066】

図５に示すように、モジュールバージョン情報一括格納部３３３は、内容フィールドＦ２１、アドレスフィールドＦ２２、データフィールドＦ２３の各フィールドを有する。これらの各フィールドが持つ意味は図４Ａに示したバージョン情報格納部３３１３Ａにおけるそれらと同一であるため、ここではこれらの説明は省略する。

【0067】

モジュールバージョン情報一括格納部３３３には、モジュールＡ部３３１Ａのバージョンに関する情報と、モジュールＢ部３３１Ｂのバージョンに関する情報とが、一括して格納される。例えば、モジュールバージョン情報一括格納部３３３の一番目のレコードには、モジュールＡ部３３１Ａのアドレス“Ｈ’００”に、モジュールＡ部３３１Ａのバージョン情報のデータである“３２Ｈ’０００１＿００００”が格納されていることが示されている。また、２番目のレコードには、モジュールＡ部３３１Ａのアドレス“Ｈ’０１”に、バージョン情報の更新日時を示すデータである“３２Ｈ’２０２２＿０５１３”が格納されていることが示されている。

【0068】

＜号機制御部内の全処理部バージョン情報格納部の構成＞
次に、図６を参照して、号機制御部４内の全処理部バージョン情報格納部４７の構成について説明する。図６は、号機制御部４内の全処理部バージョン情報格納部４７の構成例を示す図である。

【0069】

図６に示すように、全処理部バージョン情報格納部４７は、内容フィールドＦ３１、アドレスフィールドＦ３２、データフィールドＦ３３の各フィールドを有する。これらの各フィールドが持つ意味は図４Ａに示したバージョン情報格納部３３１３Ａにおけるそれらと同一であるため、ここではこれらの説明は省略する。

【0070】

全処理部バージョン情報格納部４７には、号機制御部４に接続されたすべての端末（処理部）のバージョンに関する情報が格納される。具体的には、全処理部バージョン情報格納部４７には、号機制御部４の制御対象であるホール端末３、かご内端末（図示略）、モータ部２を制御するインバータ端末（図示略）が有する各モジュールのバージョンに関する情報が一括して格納される。

【0071】

例えば、全処理部バージョン情報格納部４７の「ホール端末」の情報の格納部には、図５に示したモジュールバージョン情報一括格納部３３３に格納された情報とともに、ホール端末３＿２（図示略）～ホール端末３＿ｎ（図１参照）までの全ホール端末に格納された各モジュールのバージョンに関する情報が格納される。

【0072】

また、全処理部バージョン情報格納部４７の「かご内端末」の情報の格納部には、かご内端末に格納されているモジュールＡ部３３１Ａ及びモジュールＢ部３３１Ｂの各バージョンに関する情報が格納され、「インバータ端末」の情報の格納部には、インバータ端末に格納されているモジュールＣ部３３１Ｃ（図示略）のバージョンに関する情報が格納されている。

【0073】

＜全体管理部内のバージョン情報データベースの構成＞
次に、図７を参照して全体管理部５内のバージョン情報データベース５１の構成について説明する。図７は、全体管理部５内のバージョン情報データベース５１の構成例を示す図である。

【0074】

図７に示すように、全体管理部５内のバージョン情報データベース５１は、内容フィールドＦ４１、アドレスフィールドＦ４２、データフィールドＦ４３の各フィールドを有する。これらの各フィールドが持つ意味は図４Ａに示したバージョン情報格納部３３１３Ａにおけるそれらと同一であるため、ここではこれらの説明は省略する。

【0075】

バージョン情報データベース５１には、第１号機制御部４＿１が制御するすべての端末に格納されている全モジュールのバージョン情報が格納されている。具体的には、バージョン情報データベース５１には、第１号機制御部４＿１が制御するホール端末３＿１～３＿ｎのそれぞれに格納されている各モジュール（モジュールＡ部～Ｘ部）のバージョンに関する情報（アドレス及びデータ）が格納されている。

【0076】

また、バージョン情報データベース５１には、第１号機制御部４＿１が制御するかご端末に格納されている各モジュール（モジュールＡ部及びＢ部）のバージョンに関する情報（アドレス及びデータ）が格納されている。さらに、バージョン情報データベース５１には、第１号機制御部４＿１が制御するインバータ端末に格納されている各モジュール（モジュールＣ部）のバージョンに関する情報（アドレス及びデータ）が格納されている。

【0077】

また、バージョン情報データベース５１には、詳細の図示は省略してあるが、第２号機制御部４＿２が制御するすべての端末に格納されている全モジュールのバージョンに関する情報、及び、第３号機制御部４＿３が制御するすべての端末に格納されている全モジュールのバージョンに関する情報も格納されている。

【0078】

＜全体管理部内のＲＯＭデータベースの構成＞
次に、図８を参照して、全体管理部５内のＲＯＭデータベース５２の構成について説明する。図８は、全体管理部５内のＲＯＭデータベース５２の構成例を示す図である。

【0079】

図８に示すように、全体管理部５内のＲＯＭデータベース５２は、内容フィールドＦ５１、バージョンフィールドＦ５２、データフィールドＦ５３の各フィールドを有する。

【0080】

内容フィールドＦ５１には、モジュール情報管理システム１００が管理するすべてのモジュール（モジュールＡ部３３１Ａ～モジュールＸ部（図示略））の名称が格納される。バージョンフィールドＦ５２には、モジュールのバージョンの情報が格納される。データフィールドＦ５３の各フィールドには、モジュールの各バージョンのデータ（ＲＯＭデータ）が格納される。

【0081】

＜全体管理部によるバージョンリード処理＞
次に、図９を参照して、全体管理部５によるバージョンリード処理について説明する。図９は、全体管理部５の制御部５３によるバージョンリード処理の手順の例を示すフローチャートである。

【0082】

まず、全体管理部５の制御部５３（図１参照）は、バージョンリード定期処理の実行タイミングが到来したか否かを判定する（ステップＳ１）。バージョンリード定期は、上述したように、各端末（処理部）が有する各モジュールのバージョン情報を取得するために定期的に実行される処理であり、例えば、エレベーターのかご部１に人が乗っていない空き時間や、保守の実行時などに定期的に実行される処理である。

【0083】

ステップＳ１で、バージョンリード定期処理の実行タイミングではないと判定された場合（ステップＳ１がＮＯ判定の場合）、制御部５３は、バージョンリード指令はあるか（入力されたか）否かを判定する（ステップＳ２）。バージョンリード指示は、各モジュールのバージョンの情報を入手したいユーザによって、操作部５４（図１参照）を介して入力される指令である。

【0084】

ステップＳ２で、バージョンリード指令はないと判定された場合（ステップＳ２がＮＯ判定の場合）、制御部５３は、ＲＯＭ書き換え指令はあるか（入力されたか）否かを判定する（ステップＳ３）。ＲＯＭ書き換え指令は、上述したように、アップデート又は不具合の解消等を目的としてモジュール部のバージョン更新が行われる場合における、モジュール部のＲＯＭデータの書き換えを指示する指令である。ＲＯＭ書き換え指令も、エレベーターのかご部１に人が乗っていない空き時間や、保守の実行時などに送信される。

【0085】

ステップＳ３で、バージョンリード指令はないと判定された場合（ステップＳ３がＮＯ判定の場合）、制御部５３はステップＳ１に戻って判定を行う。一方、ステップＳ１、ステップＳ２及びステップＳ３のいずれかがＹＥＳ判定だった場合、制御部５３は、バージョンリード定期処理、バージョンリード指令、又は、ＲＯＭ書き換え指令の対象となる端末を制御する号機制御部４に対して、バージョンリード指令を送信する（ステップＳ４）。

【0086】

次いで、制御部５３は、ステップＳ４でバージョンリード指令を送信したいずれかの号機制御部４より、モジュール部のバージョン情報を受信したか否かを判定する（ステップＳ５）。ステップＳ５で、バージョン情報は受信していないと判定された場合（ステップＳ５がＮＯ判定の場合）、制御部５３は、ステップＳ５の判定を続ける。

【0087】

一方、ステップＳ５で、バージョン情報を受信したと判定された場合（ステップＳ５がＹＥＳ判定の場合）、制御部５３は、ステップＳ５で受信したバージョン情報で、バージョン情報データベース５１（図１参照）の情報を更新する（ステップＳ６）。次いで、制御部５３は、対象のすべての号機制御部４からバージョン情報を受信したか否かを判定する（ステップＳ７）。

【0088】

ステップＳ７で、対象のすべての号機制御部４からバージョン情報を受信していないと判定された場合（ステップＳ７がＮＯ判定の場合）、制御部５３はステップＳ４に戻って処理を行う。一方、ステップＳ７で、対象のすべての号機制御部４からバージョン情報を受信したと判定された場合（ステップＳ７がＹＥＳ判定の場合）、全体管理部５によるバージョンリード処理は終了する。

【0089】

＜号機制御部によるバージョンリード処理＞
次に、図１０を参照して、号機制御部４によるバージョンリード処理について説明する。図１０は、号機制御部４の制御部４８（図２参照）によるバージョンリード処理の手順の例を示すフローチャートである。

【0090】

まず、号機制御部４の制御部４８（図１参照）は、バージョンリード定期処理の実行タイミングが到来したか否かを判定する（ステップＳ１１）。ステップＳ１１で、バージョンリード定期処理の実行タイミングではないと判定された場合（ステップＳ１１がＮＯ判定の場合）、制御部４８は、バージョンリード指令はあるか（全体管理部５から送信されたか）否かを判定する（ステップＳ１２）。ステップＳ１２で、バージョンリード指令はないと判定された場合（ステップＳ１２がＮＯ判定の場合）、制御部４８は、ステップＳ１１に戻って判定を行う。

【0091】

一方、ステップＳ１１及びステップＳ１２いずれかがＹＥＳ判定だった場合、制御部４８は、バージョンリード定期処理又はバージョンリード指令の対象となる端末に対して、バージョンリード指令を送信する（ステップＳ１３）。

【0092】

次いで、制御部４８は、ステップＳ１３でバージョンリード指令を送信した端末より、モジュールのバージョン情報を受信したか否かを判定する（ステップ１４）。ステップＳ１４で、バージョン情報は受信していないと判定された場合（ステップＳ１４がＮＯ判定の場合）、制御部４８は、ステップＳ１４の判定を続ける。

【0093】

一方、ステップＳ１４で、バージョン情報を受信したと判定された場合（ステップＳ１４がＹＥＳ判定の場合）、制御部４８は、ステップＳ１４で受信したバージョン情報で、全処理部バージョン情報格納部４７（図１参照）の情報を更新する（ステップＳ１５）。

【0094】

次いで、制御部４８は、ステップＳ１２でバージョンリード指令ありと判定された場合、すなわち、バージョンリード指令を受信している場合には、全処理部バージョン情報格納部４７に格納された情報を、通信部４５を介して全体管理部５に送信する（ステップＳ１６）。

【0095】

次いで、制御部４８は、対象のすべての端末からバージョン情報を受信したか否かを判定する（ステップＳ１７）。ステップＳ１７で、対象のすべての端末からバージョン情報を受信していないと判定された場合（ステップＳ１７がＮＯ判定の場合）、制御部４８はステップＳ１３に戻って処理を行う。一方、ステップＳ１７で、対象のすべての端末からバージョン情報を受信したと判定された場合（ステップＳ１７がＹＥＳ判定の場合）、号機制御部４によるバージョンリード処理は終了する。

【0096】

＜ホール端末におけるバージョンセット処理・リード処理＞
次に、図１１を参照して、ホール端末３におけるバージョンセット処理・バージョンリード処理について説明する。図１１は、ホール端末３におけるバージョンセット処理・バージョンリード処理の手順の例を示すフローチャートである。なお、図１１では、バージョンセット処理・バージョンリード処理を行う端末（処理部）がホール端末３である例を挙げるが、これらの各処理は、かご内端末やインバータ端末（いずれも図示略）などの他の端末においても行われるものとする。

【0097】

まず、ホール端末３の各モジュール部３３１内の各機能部３３１１（図２参照）は、バージョンセット定期処理の実行タイミングが到来したか否かを判定する（ステップＳ２１）。ステップＳ２１で、バージョンセット定期処理の実行タイミングである判定された場合（ステップＳ２１がＹＥＳ判定の場合）、各機能部３３１１は、不図示のメモリ等より自身のバージョンの情報を読み出して、該情報をバージョン情報格納部３３１３にセット（格納）する（ステップＳ２２）。ステップＳ２２の処理後、ホール端末３によるバージョンセット処理は終了する。

【0098】

一方、ステップＳ２１で、バージョンセット定期処理の実行タイミングではないと判定された場合（ステップＳ２１がＮＯ判定の場合）、ホール端末３の制御部３４２は、バージョンリード定期処理の実行タイミングが到来したか否かを判定する（ステップＳ２３）。ステップＳ２３で、バージョンリード定期処理の実行タイミングであると判定された場合（ステップＳ２３がＹＥＳ判定の場合）、制御部３４２は、対象のモジュール部３３１に対して、通信部３４１及び通信部３３２を介してバージョンリード指令を送信する（ステップＳ２４）。

【0099】

次いで、制御部３４２は、いずれかのモジュール部３３１からバージョン情報を受信したか否かを判定する（ステップＳ２５）。ステップＳ２５で、バージョン情報は受信していないと判定された場合（ステップＳ２５がＮＯ判定の場合）、制御部３４２は、ステップＳ２５の判定を続ける。一方、ステップＳ２５で、バージョン情報を受信したと判定された場合（ステップＳ２５がＹＥＳ判定の場合）、制御部３４２は、受信したバージョン情報でモジュールバージョン情報一括格納部３３３の情報を更新する（ステップＳ２６）。

【0100】

次いで、制御部３４２は、すべてのモジュール部３３１のバージョン情報を受信したか否かを判定する（ステップＳ２７）。ステップＳ２７で、すべてのモジュールのバージョン情報は受信していないと判定された場合（ステップＳ２７がＮＯ判定の場合）、制御部３４２は、ステップＳ２４に戻って処理を行う。一方、ステップＳ２７で、すべてのモジュール部３３１からバージョン情報を受信したと判定された場合（ステップＳ２７がＹＥＳ判定の場合）、ホール端末３によるバージョンリード定期処理は終了する。

【0101】

ステップＳ２３で、バージョンリード定期処理の実行タイミングではないと判定された場合（ステップＳ２３がＮＯ判定の場合）、制御部３４２は、バージョンリード指令はあるか（号機制御部４から受信したか）否かを判定する（ステップＳ２８）。ステップＳ２８で、バージョンリード指令は受信していないと判定された場合（ステップＳ２８がＮＯ判定の場合）、制御部３４２は、ステップＳ２１に戻って判定を続ける。

【0102】

一方、ステップＳ２８で、バージョンリード指令を受信したと判定された場合（ステップＳ２８がＹＥＳ判定の場合）、制御部３４２は、バージョンリード指令においてバージョンリードが指示されたモジュール部のバージョン情報を、モジュールバージョン情報一括格納部３３３からリードする（読み出す）（ステップＳ２９）。次いで、制御部３４２は、リードしたバージョン情報を、通信部３４１を介して号機制御部４に送信する（ステップＳ３０）。ステップＳ３０の処理後、ホール端末３によるバージョンリード処理は終了する。

【0103】

本実施形態では、各モジュール部のバージョン情報が、ホール端末３のモジュールバージョン情報一括格納部３３３に一括して格納されるため、バージョンリード定期処理の実行時やバージョンリード指令の受信時などに、ホール端末３の制御部３４２は、各モジュール部のバージョン情報を即時にリードすることができる。

【0104】

また、不具合対応時や保守の実行時などにおいて、特定のモジュール部３３１のバージョン情報のみを取得したい場合にも、ユーザがバージョンリード指令においてモジュールを指定すれば、バージョンリード指令を受信した制御部３４２は、モジュールバージョン情報一括格納部３３３から対象のモジュール部３３１のバージョン情報をリードして、号機制御部４を介して全体管理部５に送信する。

【0105】

したがって、本実施形態では、一つのモジュール部３３１が複数の異なる端末において使用されている場合や、一つの端末において複数のモジュール部３３１が組み合わせて使用されている場合などであっても、ユーザは、所望のモジュールのバージョンの情報を、素早く適切に取得することができる。つまり、本実施形態によれば、複数の端末において共通で使用される汎用的なモジュール部のバージョン情報のトレーサビリティを向上させることができる。

【0106】

また、本実施形態では、例えば、端末に適用されるモジュールの組み合わせが運用の途中で変更された場合であっても、ユーザは、所望のモジュール部を対象としたバージョンリード指令を発行することにより、該モジュール部のバージョン情報を適切に取得することが可能となる。

【0107】

＜ＲＯＭデータ書き換え処理＞
次に、図１２を参照して、全体管理部５、号機制御部４及びホール端末３によるＲＯＭデータ書き換え処理について説明する。図１２は、全体管理部５、号機制御部４及びホール端末３によるＲＯＭデータ書き換え処理の手順の例を示すフローチャートである。なお、図１２では、ＲＯＭデータ書き換え処理を行う端末（処理部）がホール端末３である例を挙げるが、これらの各処理は、かご内端末やインバータ端末などの他の端末においても行われるものとする。

【0108】

まず、全体管理部５の制御部５３（図１参照）は、書き換えＲＯＭデータをＲＯＭデータベース５２に格納する（ステップＳ４１）。書き換えＲＯＭデータは、モジュール部３３１の不具合が修正されたＲＯＭデータ、又は、バージョンアップされた最新のＲＯＭデータである。ステップＳ４１の処理は、例えば、操作部５４に対するユーザからの操作に基づいて行われる。

【0109】

次いで、操作部５４は、ユーザによる操作に基づいて、制御部５３に対してＲＯＭ書き換え指令を発行する（ステップＳ４２）。次いで、制御部５３は、操作部５４によって発行されたＲＯＭ書き換え指令に基づいて、ＲＯＭデータベース５２を検索する（ステップＳ４３）。次いで、制御部５３は、ＲＯＭ書き換え指令に示されたバージョン情報に基づいて、バージョン情報データベース５１を検索することにより、ＲＯＭ書き換え処理を行う対象のモジュール部３３１を決定する（ステップＳ４４）。

【0110】

本実施形態では、バージョン情報データベース５１に、各端末に使用されている各モジュール部のバージョン情報がすべて格納されている。したがって、端末に複数のモジュール部が組み合わせて用いられている場合であっても、制御部５３は、バージョン情報データベース５１を検索することにより、所望のモジュール部のバージョン情報を適切に取得することができる。

【0111】

次いで、制御部５３は、ＲＯＭ書き換え対象のモジュール部３３１を備えた端末を制御する号機制御部４に対して、書き換えＲＯＭデータを送信する（ステップＳ４５）。次いで、制御部５３は、対象の号機制御部４に対して、ＲＯＭ書き換え指令を送信する（ステップＳ４６）。

【0112】

次いで、制御部５３は、ＲＯＭ書き換え指令による書き換えの対象となるすべてのモジュール部３３１を対象として、ステップＳ４５及びステップＳ４６の処理を行ったか否かを判定する（ステップＳ４７）。ステップＳ４７で、すべてのモジュール部３３１に対する処理は終了していないと判定された場合（ステップＳ４７がＮＯ判定の場合）、制御部５３は、ステップＳ４５に戻って処理を続ける。一方、ステップＳ４７で、すべてのモジュール部３３１に対する処理は終了したと判定された場合（ステップＳ４７がＹＥＳ判定の場合）、制御部５３は、ＲＯＭデータ書き換え処理を終了する。

【0113】

ステップＳ４５で制御部５３から号機制御部４に書き換えＲＯＭデータが送られると、号機制御部４の通信部４５（図１参照）は、書き換えＲＯＭデータを受信する（ステップＳ５１）。次いで、号機制御部４の制御部４８（図１参照）は、２面により構成されるＲＯＭデータ格納部４６の第２面を、ステップＳ５１で受信した書き換えＲＯＭデータにより書き換える（ステップＳ５２）。

【0114】

次いで、制御部４８は、書き換え対象のホール端末３（処理部）に対して、書き換えＲＯＭデータを送信する（ステップＳ５３）。次いで、号機制御部４の通信部４５は、全体管理部５からＲＯＭ書き換え指令を受信する（ステップＳ５４）。次いで、制御部４８は、ＲＯＭデータ格納部４６の面を、現在参照中の第１面から、ステップＳ５２で書き換えが行われた第２面に切り替える（ステップＳ５５）。

【0115】

次いで、制御部４８は、書き換えの対象のホール端末３に対して、通信部４１を介してＲＯＭ書き換え指令を送信する（ステップＳ５６）。ステップＳ５６の処理後、号機制御部４によるＲＯＭデータ書き換え処理は終了する。

【0116】

ステップＳ５３で、号機制御部４から端末に対して書き換えＲＯＭデータが送信されると、ホール端末３の通信部３４１（図２参照）は、書き換えＲＯＭデータを受信する（ステップＳ６１）。次いで、ホール端末３の制御部３４２は、２面で構成されるＲＯＭデータ格納部３３４の第２面を、ステップＳ６１で受信した書き換えＲＯＭデータにより書き換える（ステップＳ６２）。

【0117】

次いで、ホール端末３の通信部３４１は、号機制御部４からＲＯＭ書き換え指令を受信する（ステップＳ６３）。次いで、制御部３４２は、ＲＯＭデータ格納部３３４の面を、現在参照中の第１面から、ステップＳ６２で書き換えが行われた第２面に切り替える（ステップＳ６４）。ステップＳ６４の処理後、ホール端末３によるＲＯＭデータ書き換え処理を終了する。

【0118】

図１２に示した処理が行われることにより、ホール端末３は、ＲＯＭ書き換え指令を受信したタイミングで、書き換えＲＯＭデータが書き込まれた第２面の情報をすぐに参照可能になるため、処理が完了するまでエレベーターの稼働を停止させる等の制御を行わずに済む。したがって、本実施形態によれば、エレベーターの不稼働時間を最小限に抑えることができる。

【0119】

また、例えば、上述した実施形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細且つ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

【0120】

また、図１及び図２において実線、片矢印、両矢印で示した制御線又は情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

【0121】

また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。

【0122】

また、上述した本開示の一実施形態にかかるモジュール情報管理システムの各構成要素は、それぞれのハードウェアがネットワークを介して互いに情報を送受信できるならば、いずれのハードウェアに実装されてもよい。また、ある処理部により実施される処理が、１つのハードウェアにより実現されてもよいし、複数のハードウェアによる分散処理により実現されてもよい。

【符号の説明】

【0123】

１…かご部、２…モータ部、３…ホール端末、４…号機制御部、５…全体管理部、３３…ペリフェラル部、３４…全体制御部、４６…ＲＯＭデータ格納部、４７…全処理部バージョン情報格納部、４８…制御部、５１…バージョン情報データベース、５２…ＲＯＭデータベース、５３…制御部、５４…操作部、１００…モジュール情報管理システム、３３１…モジュール部、３３３…モジュールバージョン情報一括格納部、３３４…ＲＯＭデータ格納部、３４１…通信部、３４２…制御部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】