知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023094710
(43)【公開日】2023-07-06
(54)【発明の名称】エレベーターシステム及び通信エラー解析方法
(51)【国際特許分類】
B66B 5/02 20060101AFI20230629BHJP
【ＦＩ】
B66B5/02 S
【審査請求】未請求
【請求項の数】7
【出願形態】ＯＬ
(21)【出願番号】P 2021210171
(22)【出願日】2021-12-24
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110000925
【氏名又は名称】弁理士法人信友国際特許事務所
(72)【発明者】
【氏名】高木 豊和
(72)【発明者】
【氏名】出野 正樹
(72)【発明者】
【氏名】助川 祐太
(72)【発明者】
【氏名】藪内 達志
【テーマコード（参考）】
3F304
【Ｆターム（参考）】
3F304BA16
3F304BA26
3F304EA24
3F304ED01
(57)【要約】
【課題】号機制御部及び端末間における通信エラーの原因究明を適切に行えるようにする。
【解決手段】本発明の一態様のエレベーターシステム１００は、前回の周期における端末３の通信回数と、号機制御部４から送信された、前回の周期における端末３との間の通信回数との不一致の情報を端末３から受信した場合、全端末３に対して前回の周期の通信ログの送信を指示するモード切替指令処理部４７と、複数の各端末から送信された前回の周期の通信ログの情報に基づいて、通信回数の不一致を引き起こした通信エラーの解析を行う通信エラー解析部５１，設計管理部６と、を備える。
【選択図】図１
【解決手段】本発明の一態様のエレベーターシステム１００は、前回の周期における端末３の通信回数と、号機制御部４から送信された、前回の周期における端末３との間の通信回数との不一致の情報を端末３から受信した場合、全端末３に対して前回の周期の通信ログの送信を指示するモード切替指令処理部４７と、複数の各端末から送信された前回の周期の通信ログの情報に基づいて、通信回数の不一致を引き起こした通信エラーの解析を行う通信エラー解析部５１，設計管理部６と、を備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
エレベーターの号機の動作を制御する号機制御部と、前記エレベーターを構成する複数の各端末とがバス型の接続形態で接続され、所定の周期で互いに通信を行うエレベーターシステムであって、
前回の周期における前記端末の通信回数である第１の通信回数と、前記号機制御部から送信された、前回の周期における前記端末との間の通信回数である第２の通信回数とが一致するか否かを判定する通信回数ずれ判定部と、
前記通信回数ずれ判定部より、前記第１の通信回数及び前記第２の通信回数の不一致の情報を受信した場合、複数の全端末に対して前回の周期の通信ログの送信を指示する通信ログ送信指示部と、
前記通信ログ送信指示部からの指示に従って複数の各端末から送信された前回の周期の前記通信ログの情報に基づいて、前記通信回数の不一致を引き起こした通信エラーの解析を行う通信エラー解析部と、を備える
エレベーターシステム。
前回の周期における前記端末の通信回数である第１の通信回数と、前記号機制御部から送信された、前回の周期における前記端末との間の通信回数である第２の通信回数とが一致するか否かを判定する通信回数ずれ判定部と、
前記通信回数ずれ判定部より、前記第１の通信回数及び前記第２の通信回数の不一致の情報を受信した場合、複数の全端末に対して前回の周期の通信ログの送信を指示する通信ログ送信指示部と、
前記通信ログ送信指示部からの指示に従って複数の各端末から送信された前回の周期の前記通信ログの情報に基づいて、前記通信回数の不一致を引き起こした通信エラーの解析を行う通信エラー解析部と、を備える
エレベーターシステム。
【請求項2】
前記第１の通信回数をカウントする通信回数加算部をさらに備え、
前記通信回数加算部は、前記号機制御部との間で通信データが受送信される都度、及び、他の前記端末から送信された前記通信データを受信する都度、前記第１の通信回数のカウンタを加算する
請求項１に記載のエレベーターシステム。
前記通信回数加算部は、前記号機制御部との間で通信データが受送信される都度、及び、他の前記端末から送信された前記通信データを受信する都度、前記第１の通信回数のカウンタを加算する
請求項１に記載のエレベーターシステム。
【請求項3】
前記通信回数加算部は、前記通信回数の不一致の情報を送信後、又は、前記第１の通信回数と前記第２の通信回数とが一致していると判定した後に、前記第１の通信回数を加算する処理を行う
請求項２に記載のエレベーターシステム。
請求項２に記載のエレベーターシステム。
【請求項4】
前回の周期の前記通信ログには、前記通信回数加算部によって加算された前記第１の通信回数の情報も含まれる
請求項３に記載のエレベーターシステム。
請求項３に記載のエレベーターシステム。
【請求項5】
利用者による前記号機の利用状況を分析する利用状況分析部をさらに備え、
前記通信エラー解析部は、前記利用状況分析部によって前記号機の利用状況が少ないと分析された期間において、複数の前記各端末に対して前回の周期の前記通信ログの送信を要求する
請求項４に記載のエレベーターシステム。
前記通信エラー解析部は、前記利用状況分析部によって前記号機の利用状況が少ないと分析された期間において、複数の前記各端末に対して前回の周期の前記通信ログの送信を要求する
請求項４に記載のエレベーターシステム。
【請求項6】
前記号機制御部から取得した情報に基づいて、前記エレベーターの保守及び管理を行う保守管理部をさらに備え、
前記保守管理部は、前記通信回数の不一致を引き起こした前記通信エラーを前記号機制御部が検出した場合であり、かつ、該通信エラーの発生頻度が所定の閾値回数以上である場合、エラー種別を前記端末の基板故障に設定したエラー情報を、前記エレベーターの保守を行う保守員に発報する
請求項１～５のいずれか一項に記載のエレベーターシステム。
前記保守管理部は、前記通信回数の不一致を引き起こした前記通信エラーを前記号機制御部が検出した場合であり、かつ、該通信エラーの発生頻度が所定の閾値回数以上である場合、エラー種別を前記端末の基板故障に設定したエラー情報を、前記エレベーターの保守を行う保守員に発報する
請求項１～５のいずれか一項に記載のエレベーターシステム。
【請求項7】
エレベーターの号機の動作を制御する号機制御部と、前記エレベーターを構成する複数の各端末とがバス型の接続形態で接続され、所定の周期で互いに通信を行うエレベーターシステムによる通信エラー解析方法であって、
通信回数ずれ判定部が、前回の周期における前記端末の通信回数である第１の通信回数と、前記号機制御部から送信された、前回の周期における前記端末との間の通信回数である第２の通信回数とが一致するか否かを判定する手順と、
通信ログ送信指示部が、前記通信回数ずれ判定部より、前記第１の通信回数及び前記第２の通信回数の不一致の情報を受信した場合、複数の全端末に対して前回の周期の通信ログの送信を指示する手順と、
通信エラー解析部が、前記通信ログ送信指示部からの指示に従って複数の各端末から送信された前回の周期の前記通信ログの情報に基づいて、前記通信回数の不一致を引き起こした通信エラーの解析を行う手順と、を含む
通信エラー解析方法。
通信回数ずれ判定部が、前回の周期における前記端末の通信回数である第１の通信回数と、前記号機制御部から送信された、前回の周期における前記端末との間の通信回数である第２の通信回数とが一致するか否かを判定する手順と、
通信ログ送信指示部が、前記通信回数ずれ判定部より、前記第１の通信回数及び前記第２の通信回数の不一致の情報を受信した場合、複数の全端末に対して前回の周期の通信ログの送信を指示する手順と、
通信エラー解析部が、前記通信ログ送信指示部からの指示に従って複数の各端末から送信された前回の周期の前記通信ログの情報に基づいて、前記通信回数の不一致を引き起こした通信エラーの解析を行う手順と、を含む
通信エラー解析方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、エレベーターシステム及び通信エラー解析方法に関する。
【背景技術】
【0002】
従来、複数の端末と端末制御装置とが通信を行うシステムにおいて通信エラーが発生した場合、端末制御装置、又は、システムの保守を行う保守員等は、端末及び端末制御装置間の通信ログを解析することによって、通信エラーの原因究明を行う。
【0003】
特許文献１には、他の通信装置との間で発生する通信障害を解析するためにログ情報を収集する通信システムが開示されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０１９－１８００１２号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
ところで、エレベーターシステムにおいては、エレベーターの号機の動作を制御する号機制御部と、乗場や乗りかご内に設けられたボタン等の各種端末との間は、バス型の接続形態で接続されている。つまり、号機制御部から送信される各種指令等の通信データは、すべての端末に送信され、各端末から送信される通信データは、バスに接続された他の端末も経由して号機制御装置に送信される。そして、このような接続形態で接続されているために、通信エラーの原因が判明しづらい状況が発生することがある。
【0006】
号機制御部から送信される通信データはすべての端末に送信されるが、宛先が自端末でない通信データは、各端末において破棄される。しかし、ノイズ等の外乱によって通信データの宛先が化けてしまった場合、本来の宛先でない端末に該通信データが受信され、受信した端末から号機制御部に対して、通信データの返信が行われてしまうことがある。この場合、本来の宛先である端末から返信された通信データと、本来の宛先ではない端末から返信された通信データとが通信経路上で衝突してしまうと、号機制御部で通信データを正常に受信できない。
【0007】
このような状況においては、本来の宛先であった端末に異常が発生していると判断されて、該端末の通信ログの解析等が行われることがある。しかし、本来の宛先であった端末には異常がないため、通信ログの分析が行われても原因は究明されない。また、通信ログの解析によっては原因の究明を行えなかった場合、保守員は、現場にオシロスコープを持参して実際の通信の情報を解析することも行う。しかし、通信エラーの再現性が低い場合には、オシロスコープを用いた解析によっても、原因を特定できないことがある。この場合、端末の基板を交換する対策がとられることが多い。
【0008】
しかし、通信エラーの原因がノイズ等の外乱にある場合には、本来行われる必要でない基板の交換が行われることになり、余分な基板の費用、及び、基板の交換工数が発生してしまう。また、基板の交換が必要であると判断された端末ではなく、他の端末に通信エラーの原因がある場合には、通信エラーの原因と診断された端末の基板を交換しても、通信エラーが再び起こってしまうことを防げない。
【0009】
本発明は、上記の状況を考慮してなされたものであり、本発明の目的は、号機制御部及び端末間における通信エラーの原因究明を適切に行えるようにすることにある。
【課題を解決するための手段】
【0010】
本発明の一態様に係るエレベーターシステムは、エレベーターの号機の動作を制御する号機制御部と、エレベーターを構成する複数の各端末とがバス型の接続形態で接続され、所定の周期で互いに通信を行うエレベーターシステムである。本発明の一態様に係るエレベーターシステムは、前回の周期における端末の通信回数である第１の通信回数と、号機制御部から送信された、前回の周期における端末との間の通信回数である第２の通信回数とが一致するか否かを判定する通信回数ずれ判定部と、通信回数ずれ判定部より、第１の通信回数及び第２通信回数の不一致の情報を受信した場合、複数の全端末に対して前回の周期の通信ログの送信を指示する通信ログ送信指示部と、通信ログ送信指示部からの指示に従って複数の各端末から送信された前回の周期の通信ログの情報に基づいて、通信回数の不一致を引き起こした通信エラーの解析を行う通信エラー解析部と、を備える。
【0011】
また、本発明の一態様に係る通信エラー解析方法は、エレベーターの号機の動作を制御する号機制御部と、エレベーターを構成する複数の各端末とがバス型の接続形態で接続され、所定の周期で互いに通信を行うエレベーターシステムによる通信エラー解析方法である。本発明の一態様に係る通信エラー解析方法は、通信回数ずれ判定部が、前回の周期における端末の通信回数である第１の通信回数と、号機制御部から送信された、前回の周期における端末との間の通信回数である第２の通信回数とが一致するか否かを判定する手順と、通信ログ送信指示部が、通信回数ずれ判定部より、第１の通信回数及び第２通信回数の不一致の情報を受信した場合、複数の全端末に対して前回の周期の通信ログの送信を指示する手順と、通信エラー解析部が、通信ログ送信指示部からの指示に従って複数の各端末から送信された前回の周期の通信ログの情報に基づいて、通信回数の不一致を引き起こした通信エラーの解析を行う手順と、を含む。
【発明の効果】
【0012】
本発明の少なくとも一態様によれば、号機制御部及び端末間における通信エラーの原因究明を適切に行えるようになる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【0013】
【図1】本発明の一実施形態に係るエレベーターシステムの制御系の構成例を示すブロック図である。
【図2】本発明の一実施形態に係る端末の制御系の構成例を示すブロック図である。
【図3】本発明の一実施形態に係るエレベーターシステムを構成する各部の制御系の機能を実現するためのハードウェア構成例を示すブロック図である。
【図4】本発明の一実施形態に係る通信データの構成例を示す図である。
【図5】本発明の一実施形態に係る通信回数ずれ判定部による正常時における通信回数ずれ判定処理の概要を示す図である。
【図6】本発明の一実施形態に係る通信回数ずれ判定部による通信エラー発生時における通信回数ずれ判定処理の概要を示す図である。
【図7】本発明の一実施形態に係る号機制御部による処理の例を示すフローチャートである。
【図8】本発明の一実施形態に係る端末による処理の例を示すフローチャートである。
【図9】本発明の一実施形態に係る保守制御装置による処理の例を示すフローチャートである。
【発明を実施するための形態】
【0014】
以下、本発明を実施するための形態（以下、「実施形態」と称する）の例について、添付図面を参照しながら説明する。本発明は実施形態に限定されるものではなく、実施形態における種々の数値等は例示である。また、本明細書及び図面において、同一の構成要素又は実質的に同一の機能を有する構成要素には同一の符号を付することとし、重複する説明は省略する。
【0015】
＜エレベーターシステムの構成＞
図１は、本発明の一実施形態に係るエレベーターシステムの制御系の構成例を示すブロック図である。図１に示すように、エレベーターシステム１００は、エレベーター１と、巻上機２と、端末３＿１～端末３＿２と、号機制御部４と、保守管理装置５と、設計管理部６と、を含む。
図１は、本発明の一実施形態に係るエレベーターシステムの制御系の構成例を示すブロック図である。図１に示すように、エレベーターシステム１００は、エレベーター１と、巻上機２と、端末３＿１～端末３＿２と、号機制御部４と、保守管理装置５と、設計管理部６と、を含む。
【0016】
エレベーター１は、乗客が乗り降りする不図示の乗りかごを備え、不図示の昇降路内に設けられる。巻上機２は、号機制御部４によって駆動されることにより、不図示の主ロープを介して接続された乗りかご及び不図示の釣合おもりを、昇降路内で昇降させる。
【0017】
端末３は、不図示のホール（乗場）に設けられた操作盤や、乗りかご内の行き先階ボタン、表示器、スピーカーなどの、エレベーター１を構成する端末であり、号機制御部４による制御に基づいて、その表示又は放音動作等が制御される。図１においては、端末３として、乗場ボタン３＿１及び乗場ボタン３＿２が表示されているが、乗場ボタンは３つ以上あるものとする。また、以降の説明では、乗場ボタン３＿１及び乗場ボタン３＿２を区別する必要がない場合には、これらを乗場ボタン３と総称する。さらに、乗場ボタン３を端末３と称することもある。
【0018】
［号機制御部］
号機制御部４は、例えば、エレベーターの昇降路内や、不図示の機械室内に設けられ、エレベーター１の乗りかごの昇降動作や、各種端末の表示動作などを制御する。号機制御部４及び複数の各端末３間は、バス型のネットワークトポロジ（接続形態）により接続される。つまり、号機制御部４及び複数の各端末３間は、一つの共通の通信路（図示略）に接続され、号機制御部４から特定の端末３への指令は、特定の端末３以外の端末を含むすべての端末３に送信される。また、端末３から号機制御部４への通信データの送信は、号機制御部４から送信された指令等の通信データに対する返信の形態で行われ、一つの端末３から返信された通信データは、通信路に接続された他のすべての端末３でも受信される。
号機制御部４は、例えば、エレベーターの昇降路内や、不図示の機械室内に設けられ、エレベーター１の乗りかごの昇降動作や、各種端末の表示動作などを制御する。号機制御部４及び複数の各端末３間は、バス型のネットワークトポロジ（接続形態）により接続される。つまり、号機制御部４及び複数の各端末３間は、一つの共通の通信路（図示略）に接続され、号機制御部４から特定の端末３への指令は、特定の端末３以外の端末を含むすべての端末３に送信される。また、端末３から号機制御部４への通信データの送信は、号機制御部４から送信された指令等の通信データに対する返信の形態で行われ、一つの端末３から返信された通信データは、通信路に接続された他のすべての端末３でも受信される。
【0019】
号機制御部４は、かご制御部４１と、モータ制御部４２と、端末制御部４３と、通信回数送信部４４と、利用状況分析部４５と、通信エラー格納部４６と、モード切替指令処理部４７と、を含む。
【0020】
かご制御部４１は、端末制御部４３を介して各種端末３から受信した各種情報に基づいて、乗りかごのドアを開閉させたり、乗りかご内の行き先階ボタンや開閉ボタン（いずれも図示略、端末の一例）などを光らせたり、不図示の乗りかご内のスピーカー（端末の一例）から音声を放音させたりする制御を行う。
【0021】
モータ制御部４２は、巻上機２のモータ（図示略）を駆動する。これにより、巻上機２の綱車（図示略）に巻きかけられた主ロープが駆動され、該主ロープに接続された乗りかごが、昇降路内を昇降する。
【0022】
端末制御部４３は、端末３における表示又は放音動作を制御する機能部である。具体的には、端末制御部４３は、端末３としての乗場ボタンより、該ボタンの押下情報が送信されると、該ボタンに対して、ボタンを光らせる指令を送信する。また、端末制御部４３は、端末３としての行き先階ボタン（図示略）から送信された行き先階の情報を、かご制御部４１及びモータ制御部４２に送信する。
【0023】
端末３から送信されるボタンの押下情報等の各種情報は、端末制御部４３から送信される通信データに対する返信として、端末制御部４３に送信される。したがって、端末制御部４３は、各端末３に対して、所定の周期単位で通信データ（指令を含む）を送信する。号機制御部４及び各端末３間で送受信処理が行われる周期の長さは、例えば、１０～３０μｓ等に設定される。
【0024】
通信回数送信部４４は、各周期における各端末３との送受信処理の開始時に、前回の周期において各端末３との間で行われた通信データの送受信（通信）回数（第１の通信回数の一例）の情報を、端末制御部４３を介して各端末３に送信する。
【0025】
端末３では、号機制御部４から送信された通信回数、すなわち、前回の周期における号機制御部４の送受信回数と、前回の周期における自端末での通信（送受信）回数（第２の通信回数の一例）との比較が行われる。そして、両通信回数にずれがある（一致していない）場合、端末３は、号機制御部４に送信する通常データＤ２（図４参照）に、通信エラーフラグを付与する処理を行う。そして、通信エラーフラグが付与された通常データＤ２（通信回数の不一致の情報の一例）は、号機制御部４への返信を行うタイミングにおいて、号機制御部４に送信される。
【0026】
また、通信エラーフラグが付与された通常データＤ２は、号機制御部４だけでなく、他の端末３にも送信される。そして、通信エラーフラグが付与された通常データＤ２を受信した場合、端末３は、前回の周期における号機制御部４又は他の端末３との間で送受信した通信データの履歴、すなわち、通信ログを、通信ログ格納部３５（図２参照）に格納する。
【0027】
各端末３において行われる、通信ログの通信ログ格納部３５への格納は、通信エラーフラグが付与された通常データＤ２の受信をトリガとして行われるものである。つまり、各端末３の通信ログ格納部３５に格納される通信ログのうちのいずれかには、号機制御部４及び端末３間での通信回数の不一致を起こした通信エラーの情報が含まれていることが想定される。したがって、以下の説明では、通信ログ格納部３５に格納された通信ログを、通信エラーログとも称する。
【0028】
通信ログ格納部３５に格納された通信ログ（通信エラーログ）は、号機制御部４から後述する通信ログ送信モード切替指令が送信された場合に、号機制御部４への返信を行うタイミングにおいて、各端末３から号機制御部４に送信される。
【0029】
利用状況分析部４５は、端末３としての乗場ボタンの押下頻度の情報等に基づいて、曜日又は時間帯等におけるエレベーター１の利用状況を分析する。なお、利用状況分析部４５による利用状況の分析方法は、この方法に限定されない。例えば、利用状況分析部４５は、乗りかご内に設けられた不図示のカメラによる撮影画像の解析結果に基づいて、利用状況を分析してもよい。
【0030】
通信エラー格納部４６は、各端末３から送信された通信エラーログを格納する。また、通信エラー格納部４６は、保守管理装置５とネットワークを介して接続されており、格納している通信エラーログの情報を、所定の間隔毎、又は、保守管理装置５からの要求に応じて、保守管理装置５に送信する。
【0031】
モード切替指令処理部４７（通信ログ送信指示部の一例）は、各端末３にボタンの押下情報等の各種情報を送信させる「通常モード」と、各端末３が送受信した通信ログを送信させる「通信ログ送信モード」とを切り替える。モード切替指令処理部４７は、いずれかの端末３から、通信エラーフラグが付与された通常データＤ２を受信した場合、利用状況分析部４５によって利用状況が小（少ない）と分析された時間帯（期間）になったタイミングにおいて、モードを通常モードから通信ログ送信モードに切り替える。そして、モード切替指令処理部４７は、各端末３に対して、通信ログ送信モード切替指令を送信する。
【0032】
この通信ログ送信モード切替指令を受信した端末３では、自端末において格納している通信ログ（通信エラーログ）を、号機制御部４に送信する処理が行われる。
【0033】
［保守管理装置］
保守管理装置５（保守管理部の一例）は、例えば、エレベーターの監視や保守などを行う監視センター内に設けられ、号機制御部４から送信された情報に基づいて、エレベーター１を構成する各装置、端末、機器の保守及び管理を行う。保守管理装置５は、通信エラー解析部５１と、エラー情報発報部５２と、を含む。
保守管理装置５（保守管理部の一例）は、例えば、エレベーターの監視や保守などを行う監視センター内に設けられ、号機制御部４から送信された情報に基づいて、エレベーター１を構成する各装置、端末、機器の保守及び管理を行う。保守管理装置５は、通信エラー解析部５１と、エラー情報発報部５２と、を含む。
【0034】
通信エラー解析部５１は、通信エラーの発生頻度を確認し、通信エラーの発生頻度が所定の間隔未満である場合、号機制御部４の通信エラー格納部４６から取得した通信エラーログを解析することにより、通信エラーの原因を究明する。通信エラーの原因が、ノイズ等の外乱によるものではないと判定した場合、又は、通信エラーの発生頻度が所定の閾値以上である場合、通信エラー解析部５１は、通信エラーのエラー種別を「基板故障」に設定した上で、該エラー情報を、エラー情報発報部５２を介して保守員に発報する。
【0035】
また、通信エラー解析部５１は、通信エラーの発生頻度が所定の間隔未満である場合、号機制御部４の通信エラー格納部４６から取得した通信エラーログを、設計管理部６に送信し、該通信エラーログの解析を依頼する。
【0036】
エラー情報発報部５２は、号機制御部４から号機制御部４から取得したエラーの、エラー種別の情報を保守員に発報する。例えば、エラー情報発報部５２は、号機制御部４から号機制御部４から取得したエラーが通常エラーである場合には、そのエラー種別の情報を保守員に発報する。通常エラーには、例えば、基板の故障や、モーター（図示略）の異常などがある。また、エラー情報発報部５２は、通信エラー解析部５１より「基板故障」のエラー種別の情報を取得した場合には、該エラー種別の情報を保守員に発報する。
【0037】
保守員への発報は、例えば、保守員が所持する保守端末の表示画面（図示略）へのメッセージの表示や、保守端末のスピーカー（図示略）を介した音声通知等によって行われる。
【0038】
［設計管理部］
設計管理部６（通信エラー解析部の一例）は、エレベーター１の設計や管理などを行う部署に設けられ、号機制御部４からの依頼に基づいて通信エラーの解析を行い、解析結果を号機制御部４に送信する。号機制御部４から解析の依頼がある通信エラーには、発生頻度が所定の間隔未満である通信エラー等がある。
設計管理部６（通信エラー解析部の一例）は、エレベーター１の設計や管理などを行う部署に設けられ、号機制御部４からの依頼に基づいて通信エラーの解析を行い、解析結果を号機制御部４に送信する。号機制御部４から解析の依頼がある通信エラーには、発生頻度が所定の間隔未満である通信エラー等がある。
【0039】
【0040】
図２に示すように、端末３は、通信制御部３１と、通信回数加算部３２と、前回通信回数格納部３３と、通信回数ずれ判定部３４と、通信ログ格納部３５と、モード切替部３６と、入出力制御部３７と、を含む。
【0041】
通信制御部３１は、号機制御部４との間、端末３を構成する各部との間、入出力制御部３７との間で行われる通信を制御する。例えば、通信制御部３１は、号機制御部４より通信回数データＤ１を受信する処理や、通常データＤ２又は通信エラーデータＤ３を号機制御部４に送信する処理を行う。
【0042】
また、通信制御部３１は、他の端末３から、通信エラーフラグが付与された通常データＤ２（図４参照）を受信した場合に、後述する通信ログ格納部３５より前回の周期の通信ログを取得し、前回通信回数格納部３３より、前回の周期における通信回数を取得する。そして、通信制御部３１は、取得した通信ログ及び通信回数の情報を格納した通信エラーデータＤ３（図４参照）を生成する。
【0043】
通信回数加算部３２は、号機制御部４との通信の各周期において、号機制御部４との間で通信データが受送信される都度、また、他の端末３から送信された通信データを受信する都度、通信回数のカウンタ（送信カウンタ、受信カウンタ：いずれも図示略）をインクリメント（加算）する。そして、通信回数加算部３２は、その周期において加算された通信回数を、前回通信回数格納部３３に格納する。なお、通信回数加算部３２は、周期が変わるごとに加算していた通信回数をクリアしてもよく、以前の周期において加算された通信回数を引き継いでもよい。
【0044】
前回通信回数格納部３３には、通信回数加算部３２によってカウントされた通信回数が格納される。
【0045】
通信回数ずれ判定部３４は、号機制御部４から送信された、前回の周期における端末３との通信回数と、前回通信回数格納部３３に格納された、前回の周期における自端末での通信回数と、を比較する。通信回数ずれ判定部３４は、両通信回数が一致していた場合には、通常通り、通信制御部３１に号機制御部４との通信を行わせ、通信回数加算部３２に通信回数を加算させる。
【0046】
一方、両通信回数が一致していなかった場合には、通信回数ずれ判定部３４は、号機制御部４に送信する通常データＤ２（図４参照）に、通信エラーフラグを付与する。通信エラーフラグが付与された通常データＤ２は、号機制御部４から送信された通信データへの返信のタイミングで、号機制御部４に送信される。
【0047】
通信ログ格納部３５には、各周期における号機制御部４との間、及び、他の端末３との間での通信のログの情報が格納される。なお、通信ログ格納部３５に格納される通信ログは、各周期の単位でクリアされてもよく、クリアされずに蓄積されてもよい。
【0048】
モード切替部３６は、号機制御部４から送信された通信ログ送信モード切替指令を受信した場合、通信のモードを、通常モードから通信ログ送信モードに切り替える処理を行う。
【0049】
入出力制御部３７は、号機制御部４の端末制御部４３から送信された指令を、端末３を構成するボタン等の機器３０に送信したり、機器３０への乗客による操作の情報を、通信制御部３１を介して号機制御部４に送信したりする制御を行う。
【0050】
＜計算機のハードウェア構成例＞
次に、図１に示したエレベーターシステム１００を構成する各部の制御系の機能を実現するためのハードウェア構成について、図３を参照して説明する。図３は、エレベーターシステム１００を構成する各部の制御系の機能を実現するためのハードウェア構成例を示すブロック図である。
次に、図１に示したエレベーターシステム１００を構成する各部の制御系の機能を実現するためのハードウェア構成について、図３を参照して説明する。図３は、エレベーターシステム１００を構成する各部の制御系の機能を実現するためのハードウェア構成例を示すブロック図である。
【0051】
図３に示すように、計算機５０は、ＣＰＵ（Central Processing Unit）５０１と、ＲＯＭ（Read Only Memory）５０２と、ＲＡＭ（Random Access Memory）５０３と、不揮発性ストレージ５０４と、ネットワークインターフェース５０５と、を含む。計算機５０を構成する各部は、バスＢを介して相互に通信可能に接続される。
【0052】
ＣＰＵ５０１は、エレベーターシステム１００を構成する各部（端末３、号機制御部４、保守管理装置５、設計管理部６）の各機能を実現するソフトウェアのプログラムをＲＯＭ５０２から読み出し、該プログラムをＲＡＭ５０３にロードして実行する。エレベーターシステム１００を構成する各部の機能は、ＣＰＵ５０１がプログラムを実行することにより実現される。なお、ＣＰＵに代えて、ＭＰＵ（Micro Processing Unit）等の他の処理装置が用いられてもよい。
【0053】
ＲＯＭ５０２は、計算機５０によって実行されるプログラムを格納した、コンピュータ読取可能な非一過性の記録媒体の一例として用いられる。ＲＯＭ５０２には、ＯＳ（Operating System）、各種のパラメータ、計算機５０を機能させるためのプログラム等が記録される。
【0054】
ＲＡＭ５０３には、ＣＰＵ５０１の演算処理の途中で発生した変数やパラメータなどが一時的に書き込まれる。ＲＡＭ５０３に書き込まれた変数やパラメータなどは、ＣＰＵ５０１によって適宜読み出される。
【0055】
不揮発性ストレージ５０４は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フレキシブルディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリ等で構成される。なお、プログラムは、不揮発性ストレージ５０４に格納されてもよい。プログラムが不揮発性ストレージ５０４に格納される場合、不揮発性ストレージ５０４は、コンピュータによって実行されるプログラムを格納した、コンピュータ読取可能な非一過性の記録媒体の一例として用いられる。
【0056】
ネットワークインターフェース５０５は、例えば、ＮＩＣ（Network Interface Card）等で構成される。ネットワークインターフェース５０５は、ＮＩＣに接続された回線を介して、エレベーターシステム１００を構成する他の部との間で行われる各種通信データの送受信動作を制御する。
【0057】
なお、計算機５０は、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electro Luminescence）ディスプレイなどで構成される表示装置や、マウスやキーボードなどで構成される操作入力部、又は、表示装置及び操作入力部が一体に形成されたタッチパネル等を備える構成とされてもよい。
【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】
したがって、本実施形態によれば、再現性が低い通信エラーであっても、その原因を適切に究明することができる。例えば、特定の端末３を宛先として号機制御部４から送信されたパケットにノイズ等が乗って、宛先の情報が破損したことによって号機制御部４への通信データの未達が発生した場合にも、通信エラーの原因を、従来よりも短い時間で、かつ適切に解明することができる。それゆえ、本実施形態によれば、現場における保守員による保守時間を節減することができる。
【0124】
また、本実施形態では、前回の周期における全端末３での通信エラーログの情報を用いて通信エラーの原因が解析されるため、端末３側において、長期間にわたる通信ログを保存しておく必要がない。それゆえ、本実施形態によれば、通信ログ保持用のメモリの容量を節減することができる。
【0125】
さらに、本実施形態によれば、本来交換が不要である端末３の基板の交換等が行われてしまうことを防げるため、基板の購入に要する費用、及び、基板の交換作業のコストを削減することができる。
【0126】
なお、上述した実施形態は、本発明を分かりやすく説明するために装置（号機制御部、端末、保守管理装置、設計管理部）及びシステム（エレベーターシステム）の構成を詳細且つ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【0127】
例えば、端末３の通信回数ずれ判定部３４は、号機制御部４や、不図示のクラウド上などに設けられてもよい。
【0128】
また、図１又は図２中に実線の両矢印で示した制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【0129】
また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。
【0130】
さらに、上述した本開示の一実施形態にかかるエレベーターシステムの各構成要素は、それぞれのハードウェアがネットワークを介して互いに情報を送受信できるならば、いずれのハードウェアに実装されてもよい。また、ある処理部により実施される処理が、１つのハードウェアにより実現されてもよいし、複数のハードウェアによる分散処理により実現されてもよい。
【符号の説明】
【0131】
１…エレベーター、３…端末、４…号機制御部、５…保守管理装置、６…設計管理部、３１…通信制御部、３２…通信回数加算部、３３…前回通信回数格納部、３４…通信回数ずれ判定部、３５…通信ログ格納部、３６…モード切替部、３７…入出力制御部、４３…端末制御部、４４…通信回数送信部、４５…利用状況分析部、４６…通信エラー格納部、４７…モード切替指令処理部、５１…通信エラー解析部、５２…エラー情報発報部、１００…エレベーターシステム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】