特許 7698596 ソフトウェアアップデートシステム及びソフトウェアアップデート方法

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

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

(11)【特許番号】

(24)【登録日】2025-06-17

(45)【発行日】2025-06-25

(54)【発明の名称】ソフトウェアアップデートシステム及びソフトウェアアップデート方法

(51)【国際特許分類】

   B66B 3/00 20060101AFI20250618BHJP

   B66B 5/00 20060101ALI20250618BHJP

   G06F 8/65 20180101ALI20250618BHJP

【ＦＩ】

B66B3/00 S

B66B5/00 G

G06F8/65

【請求項の数】 9

(21)【出願番号】P 2022036609

(22)【出願日】2022-03-09

(65)【公開番号】P2023131710

(43)【公開日】2023-09-22

【審査請求日】2024-02-21

(73)【特許権者】

【識別番号】000005108

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

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】羽鳥 貴大

(72)【発明者】

【氏名】齊藤 勇来

(72)【発明者】

【氏名】納谷 英光

(72)【発明者】

【氏名】助川 祐太

【審査官】田中 尋

(56)【参考文献】

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

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

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

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

Ｂ６６Ｂ ３／００

Ｂ６６Ｂ ５／００

Ｇ０６Ｆ ８／６５

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

【請求項1】

エレベータの制御を行う制御装置のソフトウェアをアップデートするソフトウェアアップデートシステムであって、
前記制御装置は、
前記ソフトウェアを記憶するメモリと、
前記ソフトウェアを実行する制御部と、を備え、
前記メモリの記憶領域は、前記エレベータの制御機能の分類に対応して複数のエリアに区分され、前記ソフトウェアは、前記制御機能の分類に基づいて分割されて対応するエリアに格納され、
前記制御部は、前記ソフトウェアのアップデートを実行する場合に、当該アップデートにより変更される制御機能の分類を特定し、変更される制御機能に対応するエリアを選択的に書き換えるものであり、
前記制御機能の分類は、
複数のエレベータで共通して使用される標準機能であって変更が想定されていない不変部と、
前記標準機能であって運行を停止した状態での更新が必要な重要可変部と、
前記標準機能であって運行中の更新が可能な可変部と、
を含む
ことを特徴とするソフトウェアアップデートシステム。

【請求項2】

請求項１に記載のソフトウェアアップデートシステムであって、
前記制御機能の分類は、前記エレベータに個別に対応して設けられた機能である案件対応部を含み、
前記制御部は、
所定の切り替えトリガの入力を受け付けたことを条件に、前記重要可変部、前記可変部及び／又は前記案件対応部に対応するエリアの書き換えを実行することを特徴とするソフトウェアアップデートシステム。

【請求項3】

請求項１に記載のソフトウェアアップデートシステムであって、
前記制御部は、
前記アップデートにより変更される制御機能が格納されているエリアを判定し、
前記アップデートにより変更される制御機能によって影響を受けるエリアを判定し、
当該影響を受けるエリアを対象として動作テストを実施した上で、
前記アップデートを実行することを特徴とするソフトウェアアップデートシステム。

【請求項4】

請求項１に記載のソフトウェアアップデートシステムであって、
前記制御装置とネットワーク経由で接続され、アップデート用のソフトウェアを前記制御装置に送信するサーバをさらに備え、
前記制御装置は、前記サーバから受信した前記アップデート用のソフトウェアと既存の前記ソフトウェアとの差分を確認することで、前記アップデートにより変更される制御機能の分類を特定する
ことを特徴とするソフトウェアアップデートシステム。

【請求項5】

請求項１に記載のソフトウェアアップデートシステムであって、
前記制御装置とネットワーク経由で接続され、アップデート用のソフトウェアを前記制御装置に送信するサーバをさらに備え、
前記サーバは、
前記アップデートにより変更される制御機能を判定し、
当該変更される制御機能によって影響を受けるエリアを判定し、
当該影響を受けるエリアを対象として動作テストを実施した上で、
前記アップデート用のソフトウェアを前記制御装置に送信することを特徴とするソフトウェアアップデートシステム。

【請求項6】

エレベータの制御を行う制御装置のソフトウェアをアップデートするソフトウェアアップデート方法であって、
前記制御装置が、
アップデート用のソフトウェアを取得するステップと、
前記アップデート用のソフトウェアと既存の前記ソフトウェアとを比較し、変更される制御機能を確認するステップと、
前記変更される制御機能の分類を特定するステップと、
メモリに格納された既存の前記ソフトウェアを前記アップデート用のソフトウェアに書き換えるステップと、
を含み、
前記メモリの記憶領域は、前記エレベータの制御機能の分類に対応して複数のエリアに区分され、既存の前記ソフトウェアは、前記制御機能の分類に基づいて分割されて対応するエリアに格納されており、
前記制御装置は、前記書き換えに際し、前記変更される制御機能に対応するエリアを選択的に書き換えるものであり、
前記制御機能の分類は、
複数のエレベータで共通して使用される標準機能であって変更が想定されていない不変部と、
前記標準機能であって運行を停止した状態での更新が必要な重要可変部と、
前記標準機能であって運行中の更新が可能な可変部と、
を含む
ことを特徴とするソフトウェアアップデート方法。

【請求項7】

請求項１に記載のソフトウェアアップデートシステムであって、
前記制御装置は、各用途に合ったサブ制御装置を、備え、
前記サブ制御装置のソフトウェアアップデートは、前記制御装置経由にて実施され、前記サブ制御装置の用途に合った、通信方式、切替方式を選択され、実行されることを特徴とするソフトウェアアップデートシステム。

【請求項8】

請求項７に記載のソフトウェアアップデートシステムであって、
前記サブ制御装置は、前記制御装置にて対象のＩＤにて管理され、対象のＲＯＭデータには前記ＩＤが付与されており、前記制御装置は、前記ＩＤに従い、対象のサブ制御装置のアップデートを行うことを特徴とするソフトウェアアップデートシステム。

【請求項9】

請求項７に記載のソフトウェアアップデートシステムであって、
前記通信方式は、常時通信を止めずに、前記アップデート用の前記ソフトウェアのデータを送信すること、或いは、前記常時通信を止めて、前記アップデート用の前記ソフトウェアのデータを送信することのいずれか一つにて実施されることを特徴とするソフトウェアアップデートシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、エレベータのソフトウェアアップデートシステム及びソフトウェアアップデートに関する。

【背景技術】

【0002】

従来、エレベータ等の自動乗客搬送装置のソフトウェアを更新するため、特開２０１７－９７８８０号公報（特許文献１）に記載の技術がある。この公報には、「自動乗客搬送装置の構成要素に含まれる第１制御アプリケーションを自動更新する方法では、前記自動乗客搬送装置を運行停止させ、前記第１制御アプリケーションから第２制御アプリケーションへの切り替えを行ない、前記第２制御アプリケーションの切り替え後の点検作業を行なって前記自動乗客搬送装置が、前記第２制御アプリケーションが起動している状態で正しく動作するかどうかを判断し、前記第２制御アプリケーションの前記切り替え後の点検作業で、前記自動乗客搬送装置が正しく動作する場合、前記自動乗客搬送装置を運行させる。」という記載がある。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１７－９７８８０号公報

【発明の概要】

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

【0004】

従来の技術では、運行に影響を与えない機能についてソフトウェアのアップデートを行う場合であっても、エレベータを運行停止させ、ソフトウェア全体を更新する必要があった。このため、従来のエレベータのソフトウェアの更新は、効率的ではなかった。

【0005】

そこで、本発明では、エレベータのソフトウェアを効率的にアップデート可能な技術を提供することを目的とする。

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

【0006】

上記目的を達成するために、代表的な本発明のソフトウェアアップデートシステムの一つは、エレベータの制御を行う制御装置のソフトウェアをアップデートするソフトウェアアップデートシステムであって、前記制御装置は、前記ソフトウェアを記憶するメモリと、前記ソフトウェアを実行する制御部と、を備え、前記メモリの記憶領域は、前記エレベータの制御機能の分類に対応して複数のエリアに区分され、前記ソフトウェアは、前記制御機能の分類に基づいて分割されて対応するエリアに格納され、前記制御部は、前記ソフトウェアのアップデートを実行する場合に、当該アップデートにより変更される制御機能の分類を特定し、変更される制御機能に対応するエリアを選択的に書き換えることを特徴とする。
また、代表的な本発明のソフトウェアアップデート方法の一つは、エレベータの制御を行う制御装置のソフトウェアをアップデートするソフトウェアアップデート方法であって、前記制御装置が、アップデート用のソフトウェアを取得するステップと、前記アップデート用のソフトウェアと既存の前記ソフトウェアとを比較し、変更される制御機能を確認するステップと、前記変更される制御機能の分類を特定するステップと、メモリに格納された既存の前記ソフトウェアを前記アップデート用のソフトウェアに書き換えるステップと、を含み、前記メモリの記憶領域は、前記エレベータの制御機能の分類に対応して複数のエリアに区分され、既存の前記ソフトウェアは、前記制御機能の分類に基づいて分割されて対応するエリアに格納されており、前記制御装置は、前記書き換えに際し、前記変更される制御機能に対応するエリアを選択的に書き換えることを特徴とする。

【発明の効果】

【0007】

本発明によれば、エレベータのソフトウェアを効率的にアップデート可能な技術を提供できる。上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。

【図面の簡単な説明】

【0008】

【図1】実施例１のソフトウェアアップデートシステムの構成

【図2】ソフトウェアの構造の説明図

【図3】ＲＯＭのエリアについての説明図

【図4】機能管理テーブルの説明図

【図5】実施例１の制御装置のフローチャート

【図6】実施例２のソフトウェアアップデートシステムの構成図

【図7】動作テストの範囲についての説明図

【図8】実施例２の制御装置のフローチャート

【図9】実施例３のソフトウェアアップデートシステムの構成図

【図10】実施例３のサーバのフローチャート

【図11】実施例３の制御装置のフローチャート

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

【0009】

以下、実施例を図面を用いて説明する。

【実施例1】

【0010】

図１は、実施例１のソフトウェアアップデートシステムの構成図である。実施例１のソフトウェアアップデートシステムは、データベース１０、サーバ２０、ネットワーク３０、制御装置４０、エレベータ６０を有する。

【0011】

エレベータ６０は、乗カゴや駆動機構を有している。制御装置４０は、エレベータ６０の運行を制御する。１つの建屋に複数のエレベータ６０を設置する場合には、各エレベータ６０にそれぞれ制御装置４０が設けられる。

【0012】

制御装置４０は、ネットワーク３０を介してサーバ２０と接続する。サーバ２０は、複数の制御装置４０に関する情報をデータベース１０に登録して管理する。制御装置４０の情報には、機種、ソフトウェアのバージョン、設置場所、管理者などが含まれる。

【0013】

また、データベース１０には、制御装置４０が用いるソフトウェア自体も格納される。サーバ２０は、制御装置４０に適用可能な新たなソフトウェアがある場合に、当該ソフトウェアをアップデート用のソフトウェアとして制御装置４０に送信する。
制御装置４０は、それまで使用していた既存のソフトウェアをサーバ２０から受信したアップデート用のソフトウェアに置き換えることで、ソフトウェアのアップデートを実行する。

【0014】

制御装置４０は、その内部にＣＰＵ（Central Processing Unit）４１、ＲＡＭ（Random Access Memory）４２、ＲＯＭ（Read Only Memory）４３を有する。ＲＯＭ４３は不揮発メモリであり、ＲＡＭ４２は揮発メモリである。

【0015】

ＣＰＵ４１は、ＲＯＭ４３に格納されたソフトウェアを読み出してＲＡＭ４２に展開し、展開したソフトウェアを実行することで、制御部として動作する。
具体的には、ＣＰＵ４１は、ソフトウェアのアップデートに関し、受信部５１、差分確認部５２、データ整合部５３、伝送把握部５４及び切替部５５としての動作を行う。

【0016】

受信部５１は、サーバ２０からアップデート用のソフトウェアを受信する。差分確認部５２は、アップデート用のソフトウェアと、ＲＯＭ４３に格納されている既存のソフトウェアとの差分を確認する。この差分の確認を行うことで、ソフトウェアが提供するエレベータの制御機能のうち、どの制御機能がアップデートにより変更されるかを特定することができる。

【0017】

データ整合部５３は、アップデート用のソフトウェアを受信した場合に、受信したソフトウェアの整合性を確認する。整合性の確認は、サムチェックなど任意の手法を用いればよい。伝送把握部５４は、制御装置４０とサーバ２０とのデータの伝送状態を確認する処理を行う。切替部５５は、ＲＯＭ４３を書き換えることで、既存のソフトウェアをアップデート用のソフトウェアに切り替える。切替部５５は、切り替えに際し、所定の切り替えトリガの入力受付を条件とすることができる。切り替えトリガは、エレベータの運行を停止するなど、ソフトウェアの更新を安全に実行可能な状態で入力される信号である。

【0018】

図２は、ソフトウェアの構造の説明図である。制御装置４０のソフトウェアは、ＯＳ（Operating System）部、標準部、案件対応部、現地調整部を有する。図１に示した受信部５１、差分確認部５２、データ整合部５３、伝送把握部５４及び切替部５５は、ＯＳ部に属する。

【0019】

標準部は、エレベータの動作を制御する機能のうち、複数のエレベータで共通して使用される標準機能を提供する。案件対応部は、エレベータの動作を制御する機能のうち、案件別に個別に対応して設けられた、或いは従来あるエレベータの機能を案件特有にアレンジされた機能を提供する。例えばエレベータの報知条件を案件特有に変更するなどが挙げられる。現地調整部は、エレベータの設置時に現地で調整された機能を提供する。

【0020】

さらに、標準部は、不変部、重要可変部、可変部に分けられる。不変部は、標準機能であって、アップデートによる変更が想定されていない機能を提供する。例えば法律に関連する機能であり、納入時に第三者認定されている機能などが挙げられる。重要可変部は、標準機能であって、安全確保などのため、運行を停止した状態での更新が必要な機能を提供する。例えば、乗カゴの昇降、扉の開閉に関する機能などが、重要可変部により提供される。可変部は、標準機能であって、運行中の更新が可能な機能を提供する。例えば、乗客への報知に関する機能などが、可変部により提供される。
このように、エレベータの制御機能は、ＯＳ部、不変部、重要可変部、可変部、案件対応部、現地調整部に分類することができる。

【0021】

ＲＯＭ４３の記憶領域は、エレベータの制御機能の分類に対応して複数のエリアに区分されている。そして、ソフトウェアは、制御機能の分類に基づいて分割され、対応するエリアに格納されている。

【0022】

図３は、ＲＯＭ４３のエリアについての説明図である。図３では、ＲＯＭ４３は、エリア７１～７６に区分されている。それぞれのエリアは、先頭アドレスと、エリアサイズで規定される。エリア７１～７６には、制御機能の分類に対応付けられている。例えば、エリア７１は、ＯＳ部に対応付けられる。エリア７２は、不変部に対応付けられる。エリア７３は、重要可変部に対応付けられる。エリア７４は、可変部に対応付けられる。エリア７５は、案件対応部に対応付けられる。エリア７６は、現地調整部に対応付けられる。

【0023】

このように、ＲＯＭ４３を複数のエリアに区分し、ソフトあウェアを分割して各エリアに格納しているため、エリアを跨ぐデータの受け渡しに取り決めが必要である。そこで、各機能が格納されたアドレスを管理する機能管理テーブルを設ける。機能管理テーブルは、各機能がそれぞれ保持すればよい。もしくは、機能管理テーブルを担当するデータマネージャを設け、各機能がデータマネージャに問い合わせを行ってアクセス先を特定する構成であってもよい。

【0024】

図４は、機能管理テーブルの説明図である。図４では、機能管理テーブルは、機能Ａのアドレスと、機能Ｂのアドレスと、機能Ｃのアドレスとを管理している。機能Ａは、機能Ａの処理自体と、データ取得部と、データ更新部と、データとを含んで実現される。

【0025】

データ更新部は、外部から提供されたデータで機能Ａのデータを更新する。機能Ａの処理は、機能Ａのデータを用いて行われ、機能Ａのデータを更新する。データ取得部は、機能Ａのデータを取得して、外部に提供する。これらのデータ更新部と、データ取得部については、関数のように定義し、データの取得更新を行っても良いが、実装速度を保つために、データに対して間接テーブルを設けてプログラム上、ポインタアクセスにより、直接データをアクセスする方式でも良い。

【0026】

機能Ｂについても機能Ａと同様に、処理、データ取得部、データ更新部、データが含まれる。各機能のデータ取得部とデータ更新部は、機能管理テーブルを参照してアクセス先を特定する。このため、機能間のデータのやり取りを実現できる。

【0027】

図５は、実施例１の制御装置のフローチャートである。まず、受信部５１は、アップデート用のソフトウェアのデータであるＲＯＭデータを受信しているか否かを判定する（ステップＳ１０１）。ＲＯＭデータを受信していなければ（ステップＳ１０１；Ｎｏ）、そのまま処理を終了する。

【0028】

ＲＯＭデータを受信しているならば（ステップＳ１０１；Ｙｅｓ）、伝送把握部５４が伝送状態を確認して通信が完了したか否かを判定する（ステップＳ１０２）。通信が完了していなければ（ステップＳ１０２；Ｎｏ）、ステップＳ１０２を繰り返す。通信が完了したならば（ステップＳ１０２；Ｙｅｓ）、データ整合部５３が整合性を確認する（ステップＳ１０３）。

【0029】

整合性が確認できなければ（ステップＳ１０３；Ｎｏ）、そのまま処理を終了する。整合性が確認できれば（ステップＳ１０３；Ｙｅｓ）、差分確認部５２が差分の確認を行う。この差分の確認により、ソフトウェアが提供するエレベータの制御機能のうち、どの制御機能がアップデートにより変更されるかを特定することができる。

【0030】

変更箇所が標準部の不変部であるならば（ステップＳ１０５；Ｙｅｓ）、アップデートは不可である。そこで、切替部５５は、通信データを破棄して（ステップＳ１０６）、処理を終了する。

【0031】

変更箇所が不変部ではなく（ステップＳ１０５；Ｙｅｓ）、重要可変部であるならば（ステップＳ１０７；Ｙｅｓ）、切替部５５は、重要可変部のエリアを書き換えの対象として選択する（ステップＳ１０９）。

【0032】

変更箇所が重要可変部ではなく（ステップＳ１０７；Ｙｅｓ）、案件対応部であるならば（ステップＳ１０８；Ｙｅｓ）、切替部５５は、案件対応部のエリアを書き換えの対象として選択する（ステップＳ１１０）。

【0033】

ステップＳ１０９又はステップＳ１１０の後、切替部５５は、受信したＲＯＭデータをサブＲＯＭに書き込むことでサブＲＯＭのアップデートを行う（ステップＳ１１１）。サブＲＯＭは、例えばＲＯＭ４３と同様の不揮発メモリであり、予備用に設けられている。

【0034】

ステップＳ１１１の後、切替部５５は、切り替えトリガの入力を受け付けたか否かを判定する（ステップＳ１１２）。切り替えトリガの入力を受け付けていなければ（ステップＳ１１２；Ｎｏ）、ステップＳ１１２を繰り返すことで、切り替えトリガの入力を待機する。そして、切り替えトリガの入力を受け付けた場合に（ステップＳ１１２；Ｙｅｓ）、切替部５５は、メインＲＯＭであるＲＯＭ４３を書き換えることでアップデートを行って（ステップＳ１１３）、処理を終了する。

【0035】

変更箇所が重要可変部ではなく（ステップＳ１０７；Ｙｅｓ）、案件対応部でもなければ（ステップＳ１０８；Ｎｏ）、切替部５５は、可変部のエリアを書き換えの対象として選択する（ステップＳ１１４）。そして、メインＲＯＭであるＲＯＭ４３を書き換えることでアップデートを行って（ステップＳ１１５）、処理を終了する。

【実施例2】

【0036】

実施例２のソフトウェアアップデートシステムは、制御装置が動作テストを行う機能を備えている。
図６は、実施例２のソフトウェアアップデートシステムの構成図である。図６に示したように、実施例２の制御装置４０ａは、ＣＰＵ４１が、対象エリア判別部５６、対象テスト判別部５７及び仮想テスト実行部５８の機能をさらに実現する点が実施例１と異なる。その他の構成及び動作は実施例１と同様であるので、同一の構成要素には同一の符号を付して説明を省略する。

【0037】

対象エリア判別部５６は、アップデートにより変更される制御機能が格納されているエリアを判定する。対象テスト判別部５７は、アップデートにより変更される制御機能によって影響を受けるエリアを判定する。影響を受けるエリアとは、アップデートにより変更される制御機能が格納されているエリアと、変更された制御機能によって動作やデータが変化するエリアとを含む。仮想テスト実行部５８は、アップデートにより影響を受けるエリアを対象として、仮想的な動作テストを実施する。切替部５５は、仮想的な動作テストにより正常に動作することを確認したうえで、アップデートを実行する。

【0038】

図７は、動作テストの範囲についての説明図である。例えば、重要可変部に属する機能Ａがアップデートにより変更され、機能Ａの動作に重要可変部と案件対応部が関係する場合には、仮想テスト実行部５８は、重要可変部に対するテストＡ－１とＡ－２、案件対応部に対するテストＴＡ－１を実行する。同様に、可変部に属する機能Ｂがアップデートにより変更され、機能Ｂの動作に案件対応部と現地調整部が関係する場合には、仮想テスト実行部５８は、可変部に対するテストＢ－１、案件対応部に対するテストＴＢ－１、現地調整部に対するテストＴＢ－２を実行する。

【0039】

ここで、動作テストについては、事前に入力条件と、出力条件を規定し、機能毎にテスト条件を設けておく。テスト動作用の仮想的なデータ領域を設け、当該データ領域の入力条件と、出力条件を利用し、機能Ａを動作させ、得られた出力結果と、出力条件の一致を確認する。予め設定された出力条件と合致した場合は動作良好とし、合致しなかった場合は、動作不可とし、エラーと判断する。具体的には、機能Ａを関数で定義した場合、入力の引数を、予め設定された入力条件として引数の具体値を設定する。引数無しの関数の場合には、機能にて定義されているデータ更新部にて、予め設定された入力条件として、必要なインスタンスへのデータを更新するような入力条件を規定する。出力条件は、当該入力条件における関数の返り値、或いは、データ取得部にて必要なインスタンスへのデータを取得し、当該データ値がどのような値になるか規定したものを出力条件とする。

【0040】

また、動作テストは、テスト動作用の仮想的なデータ領域を設ける方式以外に、実際にテストモードに移行して、実際のエレベータを稼働した結果を出力条件として規定する方式でも良い。この際には、通常人が乗車しないような時間帯にて、エレベータを自動運転から切離し、乗り場のボタンに応答しないモードとする。その後、仮にエレベータを利用する利用者がいた際に同乗することを避けるために、テストモードである旨を常にエレベータ内の表示器に放置する。また荷重によって利用者を検知した場合には、テストモードである旨、及び降車を促す案内を音声、或いは、表示器に報知する。

【0041】

実際のテストについては、対象となる機能が有効となるような入力条件と出力条件を規定し、仮想的にハード入力をセットする。例えば乗り場ボタンに応答する機能を確認する場合には、入力条件は任意のフロアの乗り場ボタンの入力、任意のフロアにエレベータを待機させることであり、出力条件は、待機階から、当該フロアにエレベータが走行し、当該フロアに到着後、予め算出される時間内（例えば１０秒以内）にドアが開くことが出力条件となる。

【0042】

更に動作テストは、重要可変部、及び可変部によって起動するテスト項目をわけることを想定する。具体的には、機能から得られたデータ値を参照する、別機能のテストまで実行することは、重要可変部では設けること。可変部においては、自機能のみのテストのみ実行することとする。

【0043】

図８は、実施例２の制御装置のフローチャートである。図８のフローチャートは、ステップＳ２０１～Ｓ２０３が追加されている点が図５と異なる。その他のステップについては図５と同様であるので、同一のステップには同一の符号を付して説明を省略する。

【0044】

ステップＳ２０１は、変更対象が重要可変部である場合（ステップＳ１０７；Ｙｅｓ）に実行されるステップである。ステップＳ２０１では、テスト実行部５８は、標準部の関連エリアについて仮想テストを実行し、その後、ステップＳ１０９に進む。

【0045】

ステップＳ２０２は、変更対象が案件対応部である場合（ステップＳ１０８；Ｙｅｓ）に実行されるステップである。ステップＳ２０２では、テスト実行部５８は、案件対応部について仮想テストを実行し、その後、ステップＳ１１０に進む。

【0046】

ステップＳ２０３は、変更対象が案件対応部でない場合（ステップＳ１０８；Ｎｏ）に実行されるステップである。ステップＳ２０３では、テスト実行部５８は、可変部について仮想テストを実行し、その後、ステップＳ１１０に進む。

【実施例3】

【0047】

実施例３のソフトウェアアップデートシステムは、動作テストを行う機能をサーバに設けている。
図９は、実施例３のソフトウェアアップデートシステムの構成図である。図９に示したように、実施例２のサーバ２０ｂは、対象エリア判別部２１、対象テスト判別部２２及び仮想テスト実行部２３を備える点が実施例１と異なる。

【0048】

対象エリア判別部２１は、実施例２の対象エリア判別部５６と同様に動作する。対象テスト判別部２２は、実施例２の対象テスト判別部２２と同様に動作する。仮想テスト実行部２３は、実施例２の仮想テスト実行部５８と同様に動作する。
制御装置４０ｂは、実施例１の制御装置４０と同様の構成を有するが、その動作は異なる。

【0049】

図１０は、実施例３のサーバのフローチャートである。まず、サーバ２０ｂは、アップデート用のソフトウェアのデータであるＲＯＭデータをデータベース１０から取得する（ステップＳ３０１）。

【0050】

変更箇所が標準部の不変部であるならば（ステップＳ３０２；Ｙｅｓ）、仮想テスト実行部２３が標準部の関連エリアについて仮想テストを実施（ステップＳ３０３）する。その後、サーバ２０ｂは、対象のＲＯＭデータにおいて、不変部に変更がある旨を通知内容とし（ステップＳ３０４）、ステップＳ３１３に進む。

【0051】

変更箇所が不変部ではなく（ステップＳ３０２；Ｎｏ）、重要可変部であるならば（ステップＳ３０５；Ｙｅｓ）、仮想テスト実行部２３が標準部の関連エリアについて仮想テストを実施（ステップＳ３０６）する。その後、サーバ２０ｂは、対象のＲＯＭデータにおいて、重要可変部に変更がある旨を通知内容とし（ステップＳ３０７）、ステップＳ３１３に進む。

【0052】

変更箇所が重要可変部ではなく（ステップＳ３０５；Ｎｏ）、案件対応部であるならば（ステップＳ３０８；Ｙｅｓ）、仮想テスト実行部２３が案件対応部の関連エリアについて仮想テストを実施（ステップＳ３０９）する。その後、サーバ２０ｂは、対象のＲＯＭデータにおいて、案件対応部に変更がある旨を通知内容とし（ステップＳ３１０）、ステップＳ３１３に進む。

【0053】

変更箇所が案件対応部でなければ（ステップＳ３０８；Ｎｏ）、仮想テスト実行部２３が可変部の関連エリアについて仮想テストを実施（ステップＳ３１１）する。その後、サーバ２０ｂは、対象のＲＯＭデータにおいて、可変部に変更がある旨を通知内容とし（ステップＳ３１２）、ステップＳ３１３に進む。

【0054】

ステップＳ３１３では、通知内容として決定した変更機能を制御装置４０ｂに通知する。その後、制御装置４０ｂからメインＲＯＭの伝送準備が完了した旨の通知を受け（ステップＳ３１４）、制御装置４０ｂに対してメインＲＯＭのアップデート用のデータを伝送処理し（ステップＳ３１５）、処理を終了する。

【0055】

図１１は、実施例３の制御装置のフローチャートである。まず、受信部５１は、アップデート用のソフトウェアのデータであるＲＯＭデータを受信しているか否かを判定する（ステップＳ４０１）。ＲＯＭデータを受信していなければ（ステップＳ４０１；Ｎｏ）、そのまま処理を終了する。

【0056】

ＲＯＭデータを受信しているならば（ステップＳ４０１；Ｙｅｓ）、伝送把握部５４が伝送状態を確認して通信が完了したか否かを判定する（ステップＳ４０２）。通信が完了していなければ（ステップＳ４０２；Ｎｏ）、ステップＳ４０２を繰り返す。通信が完了したならば（ステップＳ４０２；Ｙｅｓ）、データ整合部５３が整合性を確認する（ステップＳ４０３）。

【0057】

整合性が確認できなければ（ステップＳ４０３；Ｎｏ）、そのまま処理を終了する。整合性が確認できれば（ステップＳ４０３；Ｙｅｓ）、切替部５５は、受信したＲＯＭデータをサブＲＯＭに書き込むことでサブＲＯＭのアップデートを行う（ステップＳ４０４）。

【0058】

ステップＳ４０４の後、切替部５５は、切り替えトリガの入力を受け付けたか否かを判定する（ステップＳ４０５）。切り替えトリガの入力を受け付けていなければ（ステップＳ４０５；Ｎｏ）、ステップＳ４０５を繰り返すことで、切り替えトリガの入力を待機する。そして、切り替えトリガの入力を受け付けた場合に（ステップＳ４０５；Ｙｅｓ）、切替部５５は、メインＲＯＭであるＲＯＭ４３を書き換えることでアップデートを行って（ステップＳ４０６）、処理を終了する。切り替えトリガは、前記サーバ２０から前記制御装置４０への切替指令でもよいし、現地の保守員による前記制御装置４０に設けられたスイッチや、特定の操作によって手動で切り替える方式でもどちらでも良い。また、メメインＲＯＭであるＲＯＭ４３を書き換えることは、トリガ検出した後、ソフトウェアのリセットを行い、イニシャル動作から立ち上がることが一般的である。よって、リセットから正常動作するまでに時間を要する。その際にはエレベータの利用は一時的に不可となるため、トリガ検出のみでなく、エレベータの稼働状況に応じて切替を行う方式でも良い。例えば深夜などの誰も利用しない時間帯や、運転モードはエレベータの乗り場からのサービス要求、更にはかご内の指定された行き先階への配車が完了し、無応答状態が３分経過後などの運転モードを検出した場合などである。

【0059】

上述してきたように、実施例に開示したシステムは、エレベータの制御を行う制御装置４０のソフトウェアをアップデートするソフトウェアアップデートシステムであって、前記制御装置４０は、前記ソフトウェアを記憶するメモリであるＲＯＭ４３と、前記ソフトウェアを実行する制御部としてのＣＰＵ４１とを備える。前記メモリの記憶領域は、前記エレベータの制御機能の分類に対応して複数のエリアに区分され、前記ソフトウェアは、前記制御機能の分類に基づいて分割されて対応するエリアに格納される。前記制御部は、前記ソフトウェアのアップデートを実行する場合に、当該アップデートにより変更される制御機能の分類を特定し、変更される制御機能に対応するエリアを選択的に書き換える。
かかる構成及び動作により、更新する機能よっては運行停止することなくエレベータのソフトウェアをアップデートすることができ、効率的なアップデートが実現できる。

【0060】

また、開示のシステムによれば、前記制御機能の分類は、複数のエレベータで共通して使用される標準機能であって変更が想定されていない不変部と、前記標準機能であって運行を停止した状態での更新が必要な重要可変部と、前記標準機能であって運行中の更新が可能な可変部と、前記エレベータに個別に対応して設けられた機能である案件対応部と、
を含む。
そして、前記制御部は、所定の切り替えトリガの入力を受け付けたことを条件に、前記重要可変部、前記可変部及び／又は前記案件対応部に対応するエリアの書き換えを実行する。
このため、運行の安全性に影響する可能性のある重要可変部や案件対応部に関しては、運行停止したことを示すトリガの受付を更新の条件とし、可変部については運行中に更新することができる。

【0061】

また、開示のシステムによれば、前記制御部は、前記アップデートにより変更される制御機能が格納されているエリアを判定し、前記アップデートにより変更される制御機能によって影響を受けるエリアを判定し、当該影響を受けるエリアを対象として動作テストを実施した上で、前記アップデートを実行する。
かかる構成及び動作により、更新前に効率的に動作テストを実施することができる。

【0062】

また、開示のシステムによれば、前記制御装置４０とネットワーク経由で接続され、アップデート用のソフトウェアを前記制御装置に送信するサーバ２０をさらに備え、前記制御装置４０は、前記サーバ２０から受信した前記アップデート用のソフトウェアと既存の前記ソフトウェアとの差分を確認することで、前記アップデートにより変更される制御機能の分類を特定する。
かかる構成及び動作によれば、サーバから受信したアップデート用のソフトウェアと既存のソフトウェアとの差分を効率的に確認することができる。

【0063】

また、開示のシステムによれば、前記制御装置４０とネットワーク経由で接続され、アップデート用のソフトウェアを前記制御装置４０に送信するサーバをさらに備え、前記サーバ２０は、前記アップデートにより変更される制御機能を判定し、当該変更される制御機能によって影響を受けるエリアを判定し、当該影響を受けるエリアを対象として動作テストを実施した上で、前記アップデート用のソフトウェアを前記制御装置４０に送信する。
かかる構成及び動作によれば、制御装置４０に負荷をかけることなくソフトウェアの動作を確認したうえで、アップデートを行うことができる。

【0064】

なお、本発明は上記の実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、かかる構成の削除に限らず、構成の置き換えや追加も可能である。
一例として、建屋に複数の制御装置４０が存在する場合に、サーバ２０と複数の制御装置４０との間にゲートウェイ装置を設けてもよい。ゲートウェイ装置がサーバ２０からアップデート用のソフトウェアを受信して保持し、複数の制御装置４０に適宜送信する構成とすれば、サーバ２０やネットワーク３０の負荷を軽減することができる。

【0065】

またアップデート対象が、前述した制御装置の場合では、サーバ２０から直接制御装置に対して通信で、ＲＯＭデータをバイナリで伝送する方式が考えられるが、別の装置が対象であった場合には、サーバ２０から直接制御装置４０に対して通信で、対象装置のＲＯＭデータをバイナリで送信し、制御装置４０から、対象の装置にデータを送信することが考えられる。その際に、通信データには管理ＩＤを設け、対象の装置との関連付けを行い、制御装置４０から対象の装置である旨を判断する。ＲＯＭの整合性判定については、送信されたデータと、例えばサム管理、データサイズなどによって整合性判定を行い、対象装置のアップデート通信を行う。

【0066】

サブの制御装置については、常時、制御装置４０との通信が実行されており、以下の２方式のどちらかにより、アップデート通信を実行する。

【0067】

＜方式１＞
常時通信を止めずに、通信パケットの空き領域を利用して、アップデート通信を行う方式である。これは、常時通信の空き状況を加味して、当該通信の空き状況に応じて、ＲＯＭデータを分割し、ＲＯＭデータの伝送を行う。データの分割には、制御装置４０のデータ伝送から、サブの制御装置からのＡＣＫ／ＮＡＣＫの返信時間を確保した時間帯にて伝送できる範囲で、対象データを送信する。これにより、通常の装置利用を停止することなくアップデート伝送が可能となる。

【0068】

＜方式２＞
常時通信を止めて、一時的に、対象の装置の利用を停止する。通常の装置を利用するための通信を停止し、アップデート用のＲＯＭデータの伝送のみにより、対象のデータの送信完了時間が、方式１よりも早いことがメリットとして挙げられる。

【0069】

上記のいずれかによって実行されるサブの制御装置への通信処理によって、サーバ２０から制御装置４０を経由したサブの制御装置へのデータ送信が可能となる。あとは、前述したアップデート方式に従いソフトウェアアップデートが可能となる。

【0070】

切替トリガは、制御装置４０からの伝送データを送信が完了し、サブの制御装置の切替準備完了の信号受信し、制御装置４０からサブの制御装置への切替指令によって、切替トリガとする。ここで制御装置４０の指令送信タイミングは、深夜などの誰も利用しない時間帯や、運転モードはエレベータの乗り場からのサービス要求、更にはかご内の指定された行き先階への配車が完了し、無応答状態が３分経過後などの運転モードを検出した場合などである。またサブの制御装置の対象ごとに指令送信タイミングを変更しても良い。例えば、かご内の表示器のアップデートと乗り場のボタンの制御装置については、かご内の表示器については、かご内表示器が省エネ制御に用いられるタイミングにて切り替え指令を出すことや、乗り場のボタンの制御装置については、各階存在することから、各階のデマンドに従って、切替を行うことや、シンプルにエレベータが利用されない時間帯になった時点で切り替えることなどが考えられる。これにより、各サブの制御装置の用途に合ったそれぞれの切替方式や通信方式を採用して、アップデートを行うことにより、極力使い勝手を損なわずに、新たな機能を付与することや、従来の機能の改善を実施することが可能となる。

【符号の説明】

【0071】

１０：データベース、２０：サーバ、２１：対象エリア判別部、２２：対象テスト判別部、２３：仮想テスト実行部、３０：ネットワーク、４０：制御装置、４１：ＣＰＵ、４２：ＲＡＭ、４３：ＲＯＭ、５１：受信部、５２：差分確認部、５３：データ整合部、５４：伝送把握部、５５：切替部、５６：対象エリア判別部、５７：対象テスト判別部、５８：仮想テスト実行部、６０：エレベータ、７１～７６：エリア

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】