CN118284573A - 电梯***和固件发送方法 - Google Patents

Abstract

本发明的电梯***所具有的主控制器基于电梯的运行状态来生成对多个副控制器发送固件映像的发送顺序，对于发送顺序优先的副控制器发送包括固件映像和发送顺序的数据包。发送顺序优先的副控制器从主控制器接收数据包来进行固件映像的更新，对发送顺序第二优先的副控制器发送数据包。

Description

电梯***和固件发送方法

技术领域

本发明涉及电梯***和固件发送方法。

背景技术

以往，电梯***由多个控制器构成。而且，已知以任意1台控制器对多个控制器的程序进行更新的1对N的结构更新程序的***。

专利文献1中记载了“服务器对于多个电梯中的预先决定的1台代表电梯，经由通信线路发布包括代表电梯中的更新前的版本的控制程序与要更新的最新版的控制程序的差分信息的更新数据，代表电梯基于从服务器接收到的更新数据来对自身的控制程序进行更新，并且按照预先决定的传输顺序对于下一个要传输的电梯经由网络发送更新数据”。

专利文献2中记载了“传输顺序控制单元根据经由信道对多个控制装置传输更新用的运转控制程序的传输时间、以及多个控制装置改写为更新用的运转控制程序的改写时间计算出电梯的停止时间，基于计算出的停止时间来选择对多个控制装置传输更新用的运转控制程序的顺序”。

现有技术文献

专利文献

专利文献1：日本专利第4963292号

专利文献2：日本专利第5072411号

发明内容

发明要解决的课题

如专利文献1中所记载，预先决定1台代表电梯，并且预先决定了更新数据的传输顺序的情况下，不能从代表电梯以外的电梯对更新数据进行更新。代表电梯中发生故障时，存在代表电梯的处理负载较高的情况等不能实施数据的更新处理的情况。进而，因为仅能按照预先决定的顺序执行更新处理，所以电梯仅能在决定了顺序的全部电梯能够执行更新处理的状态下完成更新处理。例如，即使仅有1台电梯发生故障或正在进行维护作业，控制处理负载较高时，因为不受理更新处理，所以存在通信处理发生延迟或发生通信中断等课题。

另外，专利文献2中，记载了基于传输时间和改写时间计算出电梯的停止时间。但是，程序容量、通信设备性能和存储设备改写性能必须符合预先规定的条件。与专利文献1中记载的技术同样地，存在不适合实际的运用状态的情况。

本发明是鉴于这样的状况得出的，目的在于与电梯的运行状态相应地变更更新固件的控制器的顺序。

用于解决课题的技术方案

本发明的电梯***具有发送固件的主控制器和接收固件来更新固件的副控制器。

主控制器基于电梯的运行状态来生成对多个副控制器发送固件的发送顺序，对于发送顺序优先的副控制器，发送包括固件和发送顺序的第一发送数据。发送顺序优先的副控制器从主控制器接收第一发送数据来进行固件的更新，对发送顺序第二优先的副控制器发送第一发送数据。

发明的效果

根据本发明，因为基于电梯的运行状态生成固件的发送顺序，所以不需要预先决定固件的发送顺序。

上述以外的课题、结构和效果，将通过以下实施方式的说明而说明。

附图说明

图1是表示本发明的一个实施方式的电梯***的整体结构例的图。

图2是表示本发明的一个实施方式的控制器的硬件结构例的框图。

图3是表示本发明的一个实施方式的包括主控制器和副控制器的数据包通信***的基本结构例的框图。

图4A是表示本发明的一个实施方式的数据包的内部结构例的图。

图4B是表示本发明的一个实施方式的主控制器、以及各副控制器中生成的数据包的例子的图。

图5是表示本发明的一个实施方式的数据包通信***的正常通信处理的例子的流程图。

图6是表示本发明的一个实施方式的副控制器的处理的例子的流程图。

图7是表示本发明的一个实施方式的异常通知消息的数据包结构例的图。

图8是表示本发明的一个实施方式的副控制器通知发生异常的处理的例子的流程图。

图9是表示本发明的一个实施方式的副控制器在数据包发送失败时进行的应对异常处理的一例的流程图。

图10是表示本发明的一个实施方式的跳过发生了通信错误的副控制器而继续进行固件的更新处理的处理的例子的流程图。

图11是表示本发明的一个实施方式的由电梯控制器和多个楼层控制器构成的树结构的例子的框图。

图12是表示本发明的一个实施方式的与是否存在楼层的呼梯登记相应的顺序的生成处理的例子的流程图。

图13是表示本发明的一个实施方式的与楼层的停留人数相应的顺序的生成处理的例子的流程图。

图14是表示本发明的一个实施方式的由群管理控制器和多个电梯控制器构成的树结构的例子的框图。

图15是表示本发明的一个实施方式的与电梯的呼梯的分配数相应的顺序的生成处理的例子的流程图。

图16是表示本发明的一个实施方式的由通信控制器和多个群管理控制器构成的树结构的例子的框图。

图17是表示本发明的一个实施方式的与对电梯的呼梯的分配数和分配处理状态相应的顺序的生成处理的例子的流程图。

图18是表示本发明的一个实施方式的群管理控制器对为了应用固件映像的重新启动进行判断的处理的例子的流程图。

图19是表示本发明的一个实施方式的电梯控制器对为了应用固件映像的重新启动进行判断的处理的例子的流程图。

图20是表示本发明的一个实施方式的楼层控制器为了应用固件映像而重新启动的处理的例子的流程图。

具体实施方式

以下，对于用于实施本发明的方式的电梯***和固件发送方法的一例，参考附图进行说明。本说明书和附图中，对于具有实质上相同的功能或结构的构成要素，通过附加相同的附图标记而省略重复的说明。另外，本发明并不限定于以下实施方式。

[一个实施方式]

图1是表示本发明的一个实施方式的电梯***100的整体结构例的图。

图1中，为了使电梯***100的说明简化而图示了1台电梯15的详细的构成要素，对于其他电梯15省略详细的构成要素的图示。

电梯***100中，为了对多个电梯15进行管理、监视运行、进行维护，例如具有相对于电梯15远程地设置的中心1。另外，电梯***100具有通信控制器3、群管理控制器4、电梯控制器5、轿厢控制器10、楼层控制器11和维护终端19。

中心1经由作为专用线路这样的有线或无线地构成的闭路网络或互联网这样的公共线路的通信网络2连接至通信控制器3。

通信控制器3是负责用于执行中心1与电梯之间的数据传输、远程操作和远程维护的通信的控制器。通信控制器3经由信道17与群管理控制器4连接。通信控制器3控制对于控制多个电梯控制器5的动作的多个群管理控制器4的通信。

群管理控制器4对控制电梯15的动作的多个电梯控制器5的动作进行控制。于是，群管理控制器4将多个电梯15合并为电梯组18进行运行控制。群管理控制器4经由信道16与多个电梯控制器5连接。

电梯15包括电梯控制器5、轿厢控制器10和楼层控制器11。

电梯控制器5控制电梯15的动作，通过实现轿厢7的上下移动和停止的控制而对使用者提供上下移动的服务。为了提供该服务，电梯控制器5控制作为主机的电动机6，对将轿厢7与平衡配重8连结的绳缆9的运动进行操作。电梯控制器5经由信道12与1台轿厢控制器10和多个楼层控制器11连接。

轿厢控制器10与使用者对在轿厢7内设置的目的地楼层按钮和门开闭按钮13的操作状况对应地进行轿厢门的开闭动作，对电梯控制器5通知轿厢状况的变化。

楼层控制器11对于电梯15升降的每个楼层设置，对电梯控制器5通知楼层的状况。例如，楼层控制器11监视各楼层中的使用者对在各楼层设置的上下按钮14的操作状况，对电梯控制器5通知楼层的状况变化。也存在代替上下按钮14而具有乘客能够在搭乘轿厢之前登记目的地楼层的目的地楼层登记装置的电梯***。

如图1所示并说明地，电梯***100是使多个控制器为1对N结构的树结构多级分层的***。另外，存在多个同一种类的控制器的情况下，也能够将该控制器中的任意一台作为树结构的根，将其余的控制器作为树结构的叶构成树结构。

中心1将各控制器中使用的固件作为固件映像31(参考后述的图3)保持在未图示的存储部中。中心1能够经由通信网络2、信道12、16、17和与信道连接的各种控制器，对任意的控制器发送固件。

与通信网络2连接的维护终端19能够从中心1复制固件。维护终端19在复制了固件之后，通过与任意的控制器连接，能够将维护终端19保持的固件输出至连接的控制器。所以，维护终端19能够使与维护终端19连接的控制器保持固件。另外，保持了固件的控制器能够对自身的固件进行更新，或对其他控制器发送固件。

另外，作为各控制器更新固件的方法，有使用固件的整体映像进行的整体更新的情况、和使用新旧固件的差分映像部分地进行差分更新的情况。

＜控制器的硬件结构例＞

接着，对于电梯***100所具有的各控制器20的硬件结构，参考图2进行说明。此处，说明通信控制器3、群管理控制器4、电梯控制器5、轿厢控制器10、楼层控制器11所具有的计算机的硬件结构。将这些总称为控制器20。

图2是表示控制器20的硬件结构例的框图。

控制器20具有与***总线21分别连接的MPU(Micro Processing Unit：微处理机)22、ROM(Read Only Memory：只读存储器)23、RAM(Random Access Memory：随机存取存储器)24和通信接口25。另外，作为与MPU类似的运算装置的上级概念有CPU(CentralProcessing Unit：中央处理器)。

MPU22、ROM23、RAM24构成处理部。本实施方式中，实现相关的各功能的程序代码的二进制数据即固件映像31(参考后述的图3)被记录在ROM23中，MPU22从ROM23读取它并载入至RAM24中，执行程序代码。另外，也存在MPU22从ROM23直接读取程序代码并直接执行程序代码的情况。

在RAM24中，暂时性地写入MPU22中进行的处理的执行途中产生的变量和参数等，从MPU22适当读取该变量和参数等。

控制器20能够通过通信接口25，在多个控制器20之间发送接收数据。作为将各控制器20之间连接的信道，例如有RS-485这样的多点形式的串行通信设备、以太网(注册商标)这样的作为提供多种拓扑结构的有线的信道的LAN(Local Area Network：局域网)、WAN(Wide Area Network：广域网)、以及作为无线的信道的RAN(Radio Area Network：无线局域网)。各控制器20例如能够通过Wi-Fi(注册商标)这样的无线或基础设施无线通信，在装置之间发送接收各控制器的数据。

另外，为了应对对ROM23改写数据时发生的故障，存在控制器20搭载多个ROM23的情况。如果是该结构，则在一方的ROM23中记录当前的固件映像31(固件的一例)，在另一方的ROM23中记录新的固件映像31。即使对后一ROM23改写新的固件映像31时发生故障，也因为前一ROM23中留有当前的固件映像31，所以能够恢复现状。另外，控制器20在存在多个ROM23的情况下，选择存储了要求的固件映像31的ROM23启动。

＜主控制器和副控制器的基本***结构＞

接着，基于图1所示的电梯***100的实施方式，对于本发明的实施方式的主控制器和副控制器的基本***结构进行说明。

图3是表示包括主控制器30和副控制器40的数据包通信***200的基本结构例的框图。

数据包通信***200是具有发送固件映像31的主控制器30和接收固件映像31并更新固件映像31的副控制器40的电梯***100的一个方式。如图1所示，电梯***100是多个控制器1对N地连接的树结构多重组合的大规模的***。此处，对于将1台控制器20作为主控制器30、将N台控制器20作为副控制器40的数据包通信***200进行说明。另外，数据包通信***200中，使同一楼层或不同楼层的控制器20成为主副关系。主副关系不仅可以在相邻的楼层中，也可以跨一个或多个楼层。例如，也能够将一个群管理控制器4作为主控制器30，跨电梯控制器5地将多个楼层控制器11作为副控制器40。

主控制器30与电梯15的运行状态相应地生成对于多个副控制器40的固件映像31的发送顺序。然后，主控制器30对于发送顺序优先的副控制器40，发送包括固件映像31和发送顺序的数据包50。主控制器30经由信道37与副控制器40连接。从主控制器30将数据包50直接发送至的副控制器40大多发送顺序在最靠前。

但是，在接收数据包50的副控制器40中发生了异常的情况下，主控制器30有时使发生了异常的副控制器40的下一个发送顺序的副控制器40优先地发送数据包50。这样，主控制器30对发送顺序优先的副控制器40发送数据包50，所以发送顺序优先的副控制器40能够接收数据包50。另外，接收了数据包50的副控制器40对发送顺序第二优先的副控制器40发送数据包50，所以数据包50在多个副控制器40中传输。因此，与主控制器30对多个副控制器40一同发布数据包50的情况相比，能够可靠地对各副控制器40发送数据包50。

该主控制器30具有固件映像31、映像分割部32、运行状态获取部33、顺序生成部34、数据包生成部35和主通信部36。

固件映像31是固件的实体。固件是对控制器20的动作进行控制的程序的一例。固件映像31被保存在主控制器30中设置的ROM23等中。

将映像分割部32用作将固件映像31分割的固件分割部的一例。映像分割部32将固件映像31分割，所以每一次通信中对副控制器40发送的数据包50的二进制数据57(参考后述的图4A)的数据量减少。能够使主控制器30与副控制器40之间的信道37的通信效率提高。

运行状态获取部33获取电梯的运行状态。电梯15的运行状态例如包括轿厢状态、呼梯的分配状态等。运行状态获取部33能够从轿厢控制器10、楼层控制器11等获取运行状态。

顺序生成部34与运行状态获取部33获取的电梯15的运行状态相应地生成用映像分割部32分割后的固件映像31的发送目的地即副控制器40的发送顺序。另外，固件映像31的文件大小充分小的情况下，存在将未分割的固件映像31发送至副控制器40的情况。

数据包生成部35(第一发送数据生成部的一例)生成主控制器30按照顺序生成部34生成的发送顺序对副控制器40发送固件映像31用的数据包50。将数据包50用作第一发送数据的一例。如后述的图4A所示，数据包生成部35生成包括识别数据包50的发送源即主控制器30的信息(发送源51)、识别数据包50的发送目的地即副控制器40的信息(发送目的地52)、发送顺序(发送顺序53)、分割后的固件映像31的构建顺序(编号56)和分割后的固件映像31(二进制数据57)的数据包50。

主通信部36对于用顺序生成部34生成的发送顺序在最靠前的副控制器40，发送用数据包生成部35生成的数据包50。

发送顺序优先的副控制器40从主控制器30接收数据包50并进行固件映像31的更新，对发送顺序第二优先的副控制器40发送数据包50。该副控制器40具有副通信部41、数据包解释部42、发送目的地提取部43、数据包生成部44、映像构建部45和固件映像存储部46。

副通信部41与信道37连接。将该副通信部41用作经由信道37从主控制器30或作为数据包50的发送源的其他副控制器40接收数据包50的第二通信部的一例。

将数据包解释部42用作对副通信部41接收到的数据包50进行解释的数据解释部的一例。数据包50的解释是按照规定的数据包格式，从数据包50提取数据而对规定的输出目的地输出数据的处理。

数据包解释部42解释得到的固件映像31的分割后的映像数据被输出至映像构建部45。另外，数据包解释部42对数据包50的解释结果被输出至发送目的地提取部43。

发送目的地提取部43基于数据包解释部42解释得到的发送顺序，提取作为数据包50的下一个发送目的地的副控制器40。

将数据包生成部44用作生成对作为数据包50的下一个发送目的地的副控制器40发送固件映像31用的数据包50(第二发送数据的一例)的第二发送数据生成部的一例。例如，数据包生成部44基于数据包解释部42对数据包50的解释结果、以及用发送目的地提取部43提取出的作为数据包的发送目的地的其余的副控制器40的发送顺序，生成新的数据包50。数据包生成部44所生成的数据包50中包括的固件映像31的分割后的映像数据基本上与副通信部41接收到的数据包50中包括的固件映像31的分割后的映像数据相同。用数据包生成部44生成数据包50时，副通信部41基于数据包50中保存的发送顺序，对作为下一个发送目的地的副控制器40发送数据包50。

将映像构建部45用作将数据包解释部42解释得到的分割后的固件映像31按照构建顺序构建为原本的固件映像31的固件构建部的一例。映像构建部45具有蓄积从数据包解释部42接收了的分割后的固件映像31的缓存(未图示)。然后，在缓存中充分蓄积了分割后的固件映像31时，对固件映像31进行重构。

固件映像存储部46存储用映像构建部45构建的固件映像31。副控制器40更新的固件映像31是从固件映像存储部46读取的。也可以在固件映像存储部46中，对多个固件映像31按每个版本进行版本管理。因此，假设更新失败的情况下，能够恢复为以前的固件映像31。

通过反复进行副控制器40的各部的处理，而基于与电梯15的运行状况相应的效率良好的副控制器40的发送顺序实现固件映像31的发送。

运行状态例如是深夜时段这样电梯***100整体处于待机状态的情况下，控制器20的顺序对更新处理造成的影响较少。所以，数据包生成部44可以使用与楼层数相应的升序/降序的顺序、对控制器20分配的序列号的顺序、或者随机数决定对副控制器40发送数据包50的顺序。

主控制器30与副控制器40的关系也可以由使用维护终端19的用户决定。另外，也可以将从维护终端19下载了固件映像31的控制器作为主控制器30，将其他控制器自动地决定为副控制器40。

＜数据包的基本结构＞

接着，对于图3所示的数据包通信***200中生成的数据包50的基本结构使用图4A和图4B进行说明。

图4A和图4B是表示数据包50的基本结构例的图。

图4A是表示数据包50的内部结构例的图。

数据包50由数据包50的发送源51的数据、数据包50的发送目的地52的数据、数据包50的发送顺序53的数据、将固件映像31分割后的映像数据54、和用于确认数据包50的数据不完整的校验数据55构成。

映像数据54是用图3所示的映像分割部32将固件映像31分割得到的多个映像数据之一。所以，映像数据54由表示固件映像31分割后的构建顺序的编号56和作为分割后的映像的实体的二进制数据57构成。通过这样定义数据包50的结构，主控制器30和副控制器40能够按照用顺序生成部34生成的多个副控制器40的顺序发送固件映像31。因此，各副控制器40能够按照接收固件映像31的顺序更新固件映像31。

另外，映像数据54或二进制数据57中，包括表示是与通信控制器3、群管理控制器4、电梯控制器5、楼层控制器11中的哪一个控制器对应的固件的识别数据。由此，是主控制器30的情况下在各控制器中搭载的映像构建部45能够根据识别数据识别面向其他控制器的固件。

图4B是表示用主控制器30和各副控制器40生成的数据包50的结构例的图。此处，设想在4层的建筑物中设置的电梯15。主控制器30对应于电梯控制器5，副控制器40对应于楼层控制器11。而且，示出了发送顺序53生成为4层-2层-3层-1层的顺序的情况。此处，在编号56中保存的“1”表示是分割后的固件映像31中的第一个二进制数据。

主控制器30生成在发送源51中设定了自身的ID编号“0”、在发送目的地52中设定了发送顺序53的最初的ID编号“4”、在发送顺序53中设定了ID编号“4”之后的顺序“2-3-1”的数据包50(1)。因此，对发送顺序53在最靠前的4层的楼层控制器11发送数据包50(1)。

4层的楼层控制器11接收数据包50(1)时，生成在发送源51中设定了自身的ID编号“4”、在发送目的地52中设定了发送顺序53的最初的ID编号“2”、在发送顺序53中设定了ID编号“2”之后的顺序“3-1”的数据包50(2)。因此，对发送顺序53在最靠前的2层的楼层控制器11发送数据包50(2)。

2层的楼层控制器11接收数据包50(2)时，生成在发送源51中设定了自身的ID编号“2”、在发送目的地52中设定了发送顺序53的最初的ID编号“3”、在发送顺序53中设定了ID编号“3”之后的顺序“1”的数据包50(3)。因此，对发送顺序53在最靠前的3层的楼层控制器11发送数据包50(3)。

3层的楼层控制器11接收数据包50(3)时，生成在发送源51中设定了自身的ID编号“3”、在发送目的地52中设定了发送顺序53的最初的ID编号“1”、因为自身是发送顺序的最后所以不设定发送顺序53的数据包50(4)。因此，对发送顺序53在最靠前的1层的楼层控制器11发送数据包50(4)。

通过使数据包50成为这样的结构，从主控制器30发送的数据包50基于与电梯15的运行状态相应的发送顺序53，顺序经由多个副控制器40发送。因此，能够减轻主控制器30的处理的负载，并且副控制器40也能够基于电梯15的运行状态效率良好地执行处理。另外，本实施方式的通信方法与从主控制器30对多个副控制器40一同发布数据包的广播相比无需占用网络。另外，主控制器30易于对固件映像31的发送顺序的分配进行管理。

另外，较多的控制器20处于待机状态的情况下，例如使用较少的深夜等情况下，由运转状态决定的控制器20的状态中差异较少。因此，也可以将发送顺序53简单地设为控制器20的ID顺序或楼层编号顺序。

另外，设想为从任意的副控制器40与主控制器30直接通信的情况下，也可以在发送源51和发送目的地52以外，对数据包追加与主控制器30相当的数据包的发送源的项目。从副控制器40对主控制器30的通信例如是为了对主控制器30通知副控制器40管理的范围的电梯15的运行状况而进行的。另外，从副控制器40对主控制器30的通信在电梯15的通常运转中的状态通知中使用。另外，也为了副控制器40无需反向经过多个副控制器40地对主控制器30直接发送故障信息而使用。

＜正常时的通信处理＞

接着，对于图3所示的数据包通信***200中的处理(固件发送方法的一例)，参考图5以后的流程图进行说明。

图5是表示数据包通信***200的正常通信处理的例子的流程图。图5示出了主控制器30将固件映像31分割、按照基于电梯15的运行状态生成的顺序发送数据包50，由此对全部副控制器40发布固件映像31的处理。

首先，主控制器30的映像分割部32(参考图3)将固件映像31分割为适合通信的大小(S1)。映像分割部32在对固件映像31进行分割时，为了可以得知分割顺序，例如也生成升序的编号56(参考图4A)。另外，存在最后分割的固件映像31的编号设为特别的末端编号的情况。如果数据包50的接收方的控制器20共享该末端编号，则即使分割的固件映像31的个数较多，控制器20也能够接收至最后。

接着，运行状态获取部33获取电梯15的运行状态(S2)。接着，顺序生成部34基于运行状态，生成对分割的固件映像31进行通信传输的副控制器40的顺序(S3)。接着，数据包生成部35按照用顺序生成部34生成的顺序，生成对下一个副控制器40发送的数据包50(S4)。然后，主通信部36将所生成的数据包50按照顺序发送至下一个副控制器40(S5)。

主通信部36确认数据包50的发送是否成功(S6)。数据包50的发送失败的情况下(S6的否)，主通信部36接收来自副控制器40的异常通知之后(S7)，结束本处理。另外，一定时间之后，主控制器30为了再次发送数据包50而再次执行本处理。

另一方面，数据包50的发送成功的情况下(S6的是)，主通信部36确认是否存在将固件映像31分割后的剩余部分(S8)。存在将固件映像31分割后的剩余部分的情况下(S8的是)，主控制器30返回步骤S1，反复进行处理。不存在剩余部分的情况下(S8的否)，主控制器30结束本处理。

接着，对于副控制器40的处理，参考图6进行说明。

图6是表示副控制器40的处理的例子的流程图。

首先，副控制器40的副通信部41从主控制器30或顺序为前一个的副控制器40接收数据包50(S11)。

接着，数据包解释部42对副通信部41接收到的数据包50进行解释(S12)，分别识别发送源51、发送目的地52、发送顺序53、分割后的映像数据54、校验数据55。步骤S12的解释数据包50的处理在后述的图8中示出详细的例子。

接着，发送目的地提取部43从数据包解释部42识别出的发送顺序53中提取下一个发送目的地(S13)。另外，映像构建部45用分割后的映像数据54依次构建固件映像31(S14)。步骤S13、S14的处理可以是并行处理，也可以是逐次处理。

接着，发送目的地提取部43根据发送顺序53确认是否存在发送分割后的映像数据54的下一个发送目的地(S15)。

存在下一个发送目的地的情况下(S15的是)，数据包生成部44生成将发送目的地52新变更为下一个副控制器40的数据包50(S16)。副通信部41将所生成的数据包50发送至下一个副控制器40(S17)，确认数据包50的发送是否成功(S18)。

数据包50的发送失败的情况下(S18的否)，副控制器40进行后述图7或图10所示的应对异常处理(S19)。步骤S19如后述的图9和图10所示地有不同的跳转目的地。

另一方面，数据包50的发送成功的情况下(S18的是)，或者步骤S15中判断为不存在发送分割后的映像数据54的下一个副控制器40的情况下(S15的否)，数据包解释部42确认映像数据54是否为固件映像31的末端(S20)。

如果是固件映像31的末端(S20的是)，则数据包解释部42在确认映像构建部45对固件映像31的构建结束之后，副控制器40结束本处理。另一方面，如果不是固件映像31的末端(S20的否)，则返回步骤S11，副控制器40反复进行处理。

另外，副通信部41也可以在每次接收包括分割后的映像数据54的数据包50时，存储数据包解释部42解释得到的发送源51。该情况下，副通信部41也能够通过对数据包50的顺序反向回溯地进行通信，而与主控制器30进行通信。例如，副通信部41也能够对主控制器30通知副控制器40发生故障。

通过图5和图6所示的处理流程，主控制器30仅通过对与电梯15的运行状态相应的顺序的最初的副控制器40发送数据包50，无需自身对全部多个副控制器40发布固件映像31，就能够进行固件映像31的更新。多个副控制器40按照主控制器30生成的顺序，对其他副控制器40进行固件映像31的通信传输。这样，主控制器30通过将效率良好的通信处理组合，能够对全部副控制器40的固件映像31进行更新。

另外，固件映像31的大小较小、或者差分更新中差分映像的数据长度较小的情况下，存在不进行映像分割地对数据包50进行通信传输的情况。该情况下，也存在通过一次通信就完成主控制器30与副控制器40的处理的情况。

＜通信异常的通知处理＞

接着，对于发生通信异常时副控制器40对主控制器30通知发生异常的处理，使用图7～图10进行说明。

首先，说明本处理中使用的异常通知消息的结构例。

图7是表示异常通知消息的数据包结构例的图。

接收到数据包50时检测出通信异常的副控制器40对数据包50的发送源即前一级的副控制器40发送异常通知消息。

该异常通知消息如图7所示，由发送源51的数据、发送目的地52的数据、映像数据54的数据和校验数据55构成。另外，在发送顺序53中没有存储数据。

然后，映像数据54由命令58和与该命令58对应的命令数据59构成。本实施方式中，在命令58中保存“通知发生异常命令”，在命令数据59中保存发生了通信异常的控制器20的ID。

图8是表示副控制器40通知发生异常的处理的例子的流程图。此处，说明图6的步骤S12所示的数据包解释处理的详细的例子。

首先，任意的控制器20的数据包解释部42对数据包50进行解释，确认发送顺序53的数据(S21)。接着，数据包解释部42确认发送顺序53的数据中是否按数据包50的发送顺序保存了发送目的地的副控制器40的ID(S22)。发送顺序53的数据中按发送顺序保存了副控制器40的ID的情况下(S22的是)，离开本处理，转移至图6的步骤S13。

另一方面，发送顺序53的数据中没有按发送顺序保存副控制器40的ID的情况下(S22的否)，在映像构建部45对固件映像31的更新途中发生了异常。该情况下，副通信部41按与发送顺序相反的顺序对主控制器30发送包括关于异常的信息的数据。因此，主控制器30能够立即得知副控制器40中发生的异常，采取停止发送数据包50等的指示等措施。

例如，数据包解释部42根据映像数据54，对图7所示的命令58和与命令58对应的命令数据59进行解释(S23)。然后，数据包解释部42生成将发送源51设为执行本处理的副控制器40本身、将发送目的地52置换为发送了数据包50的前一个的副控制器40的异常通知消息(S24)。

副控制器40的副通信部41将异常通知消息发送至发送顺序在前的副控制器40(S25)。之后，映像构建部45删除此前构建的固件映像31(S26)，结束处理。因此，不进行图6的步骤S13、S14以后的处理。

通过图8所示的异常通知的处理流程，副控制器40能够在发生了通信异常时删除处理途中的固件映像31。另外，副控制器40能够对主控制器30通知异常通知消息。

＜异常时的通信处理＞

接着，对于发生了通信错误的异常时、接收了数据包50的副控制器40将构建途中的映像删除的情况、以及跳过发生了通信错误的副控制器40的情况下的各处理，使用图9和图10进行说明。

＜第一异常通知处理＞

图9是表示副控制器40在数据包50发送失败时进行的应对异常处理的一例的流程图。该应对异常处理中，副控制器40在数据包50发送失败时，进行将此前对发送目的地的副控制器40发送的映像数据54删除的处理。另外，步骤S17之前的处理如图6所示的一般，因此省略详细的说明。

如图6所示，任意的控制器20的副通信部41对下一个控制器20发送所生成的数据包50(S17)。作为任意的控制器20，例如有通信控制器3、群管理控制器4、电梯控制器5、轿厢控制器10、楼层控制器11。接着，副通信部41确认数据包50的发送是否成功(S18)。

数据包50的发送成功的情况下(S18的是)，控制器20转移至图6的步骤S20以后的处理。另一方面，数据包50的发送失败的情况下(S18的否)，在映像构建部45对固件映像31的更新途中发生异常。

该情况下，副通信部41按照与发送顺序相反的顺序对主控制器30发送包括关于异常的信息的数据。因此，主控制器30能够立即得知副控制器40中发生的异常，采取停止发送数据包50等的指示等措施。另外，副控制器40在固件映像31的更新途中发生了异常的情况下，将映像构建部45已构建的固件映像31删除。所以，副控制器40中，不会使用不正确的固件映像31进行更新处理。

例如，控制器20的数据包生成部44生成用于对顺序在前的控制器20通知通信异常的异常通知消息的数据包50(S31)。接着，副通信部41对顺序在前的控制器20发送异常通知消息的数据包50(S32)。然后，映像构建部45将此前构建的固件映像31删除(S33)，结束本处理。

＜第二异常通知处理＞

图10是表示跳过发生了通信错误的副控制器40、继续进行固件映像31的更新处理的处理的例子的流程图。该应对异常处理中，优先对没有发生通信错误的副控制器40进行数据包50的发送。例如，设想控制器20是副控制器40。该情况下，副控制器40在从作为数据包50的下一个发送目的地的副控制器40接收了包括关于在固件映像31的更新途中发生的异常的信息的数据的情况下，跳过发送了包括关于异常的信息的数据的副控制器40，对后续的副控制器40发送数据包50。结果，能够使发生了异常的副控制器40的更新处理延后，先进行其他副控制器40的更新处理。所以，能够早期地提高副控制器40的更新处理的完成率。另外，步骤S16之前的处理如图6所示的一般，因此省略详细的说明。

如图6所示，任意的控制器20的数据包生成部44生成数据包50(S16)，副通信部41发送数据包50(S17)。接着，副通信部41确认数据包50的发送是否成功(S18)。

数据包50的发送成功了的情况下(S18的是)，控制器20转移至图6的步骤S20以后的处理。另一方面，数据包50的发送失败的情况下(S18的否)，控制器20进行步骤S19的应对异常处理。

于是，控制器20的数据包生成部44生成用于对顺序在发生了通信异常的控制器20下一个的控制器20通知通信异常的异常通知消息的数据包50(S41)。本处理中，命令58是“通知发生跳过命令”，命令数据59是“发生了通信异常的控制器20的ID”。

接着，副通信部41对顺序在发生了通信异常的控制器20下一个的控制器20发送异常通知消息的数据包50(S42)。然后，映像构建部45将数据更新为跳过发送数据包50失败的控制器20的发送顺序53(S43)，转移至步骤S16。

之后，控制器20基于更新后的发送顺序53在步骤S16中生成数据包50。该数据包50是控制器20对跳转目的地的控制器20重新发送固件映像31的数据包，步骤S17中发送的数据包50的发送目的地是跳转目的地的控制器20。

通过这样的处理流程，即使在发生通信异常时，主控制器30也能够继续进行对副控制器40的固件映像31的更新。另外，副控制器40能够对主控制器30通知因该通信异常而跳过的副控制器40的信息。所以，主控制器30能够通过图10所示的处理流程对于跳过的副控制器40再次执行固件映像31的更新。

另外，主控制器30再次执行固件映像31的更新时，需要从主控制器30对副控制器40发送将命令58设为“删除映像命令”的数据包50。删除映像命令用于在副控制器40中残留有固件映像31的残余数据的情况下，由主控制器30对副控制器40指示删除固件映像31的残余数据。

[树结构]

接着，对于从图1所示的电梯***100中提取成主控制器30与副控制器40的关系的控制器的各种树结构进行说明。

＜电梯控制器+楼层控制器的结构＞

首先，对于由电梯控制器5和多个楼层控制器11构成的树结构，使用图11进行说明。

图11是表示由电梯控制器5和多个楼层控制器11构成的树结构的例子的框图。

1台电梯15是用信道12将一个电梯控制器5和相当于楼层数M的楼层控制器11(1)～11(M)连接的树结构。

设想从上级的群管理控制器4将固件映像31下载至电梯控制器5的情况。而且，是电梯控制器5或多个楼层控制器11中存储了固件映像31的一个控制器是主控制器30、其他是副控制器40的结构。例如，电梯控制器5作为主控制器30，楼层控制器11作为副控制器40。主控制器30对副控制器40发送包括发送顺序的数据包50，接收了数据包50的副控制器40对固件映像31进行更新。通过这样使电梯控制器5、与多个楼层控制器11(1)～11(M)成为主控制器30和副控制器40的关系，能够不限定于一个控制器地进行副控制器40的固件映像31的更新处理。

另外，存在任意的楼层控制器11经由电梯控制器5下载固件映像31的情况。该情况下，一个楼层控制器11作为主控制器30，除此以外的楼层控制器11和电梯控制器5作为副控制器40。采用这样的结构的情况下，树结构的下级的控制器(楼层控制器)11是主控制器30，上级的控制器(电梯控制器5)是副控制器40。

因此，作为主控制器30的楼层控制器11能够从电梯控制器5获取各楼层的呼梯登记信息。反之，电梯控制器5也能够从各楼层控制器11获取呼梯登记信息。因此，根据本实施方式，数据包通信***200能够不受树结构的上级、下级的区分的限定地工作。

另外，与维护终端19连接并下载了固件映像31的控制器20作为主控制器30的情况下，与该控制器20连接至相同的段的其他控制器20作为副控制器40。此处，连接至相同的段的其他控制器20，在主控制器30是通信控制器3的情况下，是群管理控制器4。另外，主控制器30是群管理控制器4的情况下，是电梯控制器5。另外，主控制器30是电梯控制器5的情况下，是轿厢控制器10和楼层控制器11。

＜与是否存在楼层的呼梯登记相应的顺序的生成处理＞

接着，对于电梯控制器5基于作为运行状态之一的各楼层中的呼梯登记来生成发送顺序53的数据的处理，使用图12进行说明。

图12是表示与是否存在楼层的呼梯登记相应的顺序的生成处理的例子的流程图。

此处，用作主控制器30的电梯控制器5与从楼层控制器11作为运行状态获取的各楼层的呼梯登记的状况相应地生成发送顺序，与楼层的停留人数的状况相应地重新排列发送顺序。因此，生成与楼层控制器11的呼梯登记的处理负载相应的发送顺序。另外，因为与楼层的停留人数的状况相应地得知电梯15的每个楼层的运转状况，所以通过重新排列对楼层控制器11的发送顺序，而从负载低的楼层控制器11起依次更新固件映像31。

首先，电梯控制器5的运行状态获取部33从各楼层的楼层控制器11获取各楼层的呼梯登记信息(S51)。接着，电梯控制器5判断是否已获取全部楼层的呼梯登记信息(S52)。

已获取全部楼层的呼梯登记信息的情况下(S52的是)，电梯控制器5的顺序生成部34与获取的呼梯登记信息相应地，排列楼层控制器11的发送顺序并生成发送顺序53的数据(S53)，结束本处理。发送顺序的排列，按是否存在呼梯登记和呼梯登记的升序进行。

另一方面，留有尚未获取呼梯登记信息的楼层的情况下(S52的否)，电梯控制器5再次返回步骤S51，持续进行步骤S51、S52的处理直至获取全部楼层的呼梯登记信息。

此处，在尚未获取呼梯登记信息的楼层中，没有对楼层控制器11分配处理。此处，上下的呼梯的一方存在登记的情况下，分配了处理。进而，存在上下双方的呼梯登记的情况下，处理的负载最大。

因此，顺序生成部34通过生成与对楼层的呼梯登记信息的分配相应的发送顺序53的数据，能够将没有分配处理的楼层控制器11设为顺序在前，将分配处理较多的楼层控制器11设为顺序在后地应用固件映像31。另外，在群管理控制器4对各楼层的呼梯登记信息一并地进行管理的情况下，电梯控制器5也可以从群管理控制器4一并地获取各楼层的呼梯登记信息。

另外，顺序生成部34通过将固件映像31的发送顺序设为与电梯15的运行信息相应的顺序，能够从没有分配处理的楼层控制器11起更新固件映像31。所以，电梯控制器5能够效率良好地进行更新数据的通信传输。另外，电梯控制器5能够为了对楼层控制器11应用更新后的新的固件映像31而立即使楼层控制器11重新启动的可能性提高。

＜与各楼层的停留人数相应的顺序的生成处理＞

接着，对于电梯控制器5基于作为运行状态之一的各楼层的停留人数来生成发送顺序53的数据的处理，使用图13进行说明。此处，停留人数是预测位于各楼层中的人数。通过对每个楼层计算从轿厢对楼层乘降的人数能够求出停留人数。

图13是表示与楼层的停留人数相应的顺序的生成处理的例子的流程图。

首先，电梯控制器5的运行状态获取部33从其他电梯控制器5、或各楼层的楼层控制器11，获取各楼层的停留人数(S61)。

接着，电梯控制器5确认是否已获取全部楼层的停留人数(S62)。存在尚未获取停留人数的楼层的情况下(S62的否)，电梯控制器5再次返回步骤S61，持续进行步骤S61、S62的处理直至获取全部楼层的停留人数。

另一方面，已获取全部楼层的停留人数的情况下(S62的是)，电梯控制器5的顺序生成部34与各楼层的停留人数相应地，排列对楼层控制器11的数据包50的发送顺序(S63)，生成发送顺序53的数据。之后结束本处理。

排列的发送顺序例如设为停留人数的升序。因为停留人数较多时发生呼梯的概率高，所以处理负载较大的可能性高。反之，因为停留人数较少时，发生呼梯的概率低，所以处理存在余力的可能性高。

因此，通过生成与该停留人数相应的发送顺序53的数据，能够按照将处理存在余力的楼层控制器11设为最先、将存在处理负载大的可能性的楼层控制器11设为最后的顺序应用固件映像31。另外，在群管理控制器4对各楼层的停留人数一并地进行管理的情况下，电梯控制器5也可以从群管理控制器4获取各楼层的停留人数。另外，在电梯控制器5自身管理各楼层的停留人数的情况下，也可以使用该管理数据。

这样，电梯控制器5通过与电梯15的运行信息(各楼层的停留人数)相应地排列对楼层控制器11的发送顺序，能够从处理存在余力的楼层控制器11起更新固件映像31。因此，电梯控制器5能够对楼层控制器11效率良好地发送固件映像31的更新数据。另外，接收了固件映像31的更新数据的楼层控制器11能够为了应用更新后的新的固件映像31而立即重新启动的可能性提高。

＜群管理控制器+电梯控制器＞

接着，对于用信道16将多个电梯15和群管理控制器4连接构成的树结构，使用图14进行说明。

图14是表示由群管理控制器4和多个电梯控制器5构成的树结构的例子的框图。此处，图1所示的电梯组18包括1台群管理控制器4、和与存在任意数量的电梯15(1)～15(M)分别对应地设置的多个电梯控制器5。

此处，群管理控制器4或多个电梯控制器5中，存储了固件映像31的一个是主控制器30，其他作为副控制器40。该情况下，主控制器30将包括发送顺序的数据包50发送至副控制器40，接收了数据包50的副控制器40对固件映像31进行更新。

于是，设想从上级的通信控制器3将固件映像31下载至群管理控制器4的情况。该情况下，是群管理控制器4作为主控制器30、多个电梯控制器5作为副控制器40的结构。通过这样使群管理控制器4、与多个电梯控制器5成为主控制器30与副控制器40的关系，能够不限定于一个控制器地进行副控制器40的固件映像31的更新处理。

另外，存在任意的电梯控制器5经由群管理控制器4下载固件映像31的情况。该情况下，是一个电梯控制器5作为主控制器30、除此以外的电梯控制器5和群管理控制器4作为副控制器40的结构。如果是本实施方式的结构，则作为主控制器30的一个电梯控制器5能够从作为副控制器40的群管理控制器4或其他电梯控制器5获取对各电梯控制器5分配的呼梯的呼梯数。

另外，与维护终端19连接并下载了固件映像31的控制器20作为主控制器30的情况下，与该控制器20连接至相同的段的其他控制器20作为副控制器40。此处，作为下载了固件映像31的控制器20，例如设想为电梯控制器5、轿厢控制器10或楼层控制器11。

＜与电梯的呼梯分配是否存在和大小相应的顺序的生成处理＞

接着，对于群管理控制器4基于作为运行状态之一的电梯15的呼梯的分配数来生成发送顺序53的数据的处理，使用图15进行说明。

图15是表示与电梯15的呼梯的分配数相应的顺序的生成处理的例子的流程图。该处理中，主控制器30的顺序生成部34与作为运行状态获取的、对多个电梯15的呼梯分配的状况相应地生成发送顺序。因此，生成与电梯控制器5的处理的负载相应的发送顺序。

首先，群管理控制器4的运行状态获取部33获取对各电梯15分配的呼梯的分配数(S71)。接着，群管理控制器4的顺序生成部34与呼梯的分配数相应地排列电梯控制器5的发送顺序并生成发送顺序53的数据(S72)，结束本处理。

发送顺序的排列按照呼梯的分配数的升序进行。呼梯的分配数较多时，轿厢7对于分配了呼梯的楼层的移动、停止、出发的处理次数较多，因此，存在电梯控制器5的处理负载也较大的可能性。反之，呼梯的分配数较少时、电梯控制器5的处理负载较小。另外，电梯控制器5转移至停止即待机状态的可能性提高。

另外，群管理控制器4的顺序生成部34通过将对电梯控制器5的固件映像31的发送顺序设为与电梯15的运行状态相应的顺序，能够从处理存在余力、或者最近成为待机状态的可能性较高的电梯控制器5起更新固件映像31。所以，电梯控制器5能够效率良好地进行更新数据的通信传输。另外，群管理控制器4能够为了对电梯控制器5应用更新后的新的固件映像31而立即使电梯控制器5重新启动的可能性提高。

＜通信控制器+群管理控制器＞

接着，对于用信道17将多个电梯组18与通信控制器3连接的树结构，使用图16进行说明。

图16是由通信控制器3和多个群管理控制器4构成的树结构的例子的框图。此处，示出图1所示的1台通信控制器3和与存在任意数量的电梯组18(1)～18(M)分别对应地设置的多个群管理控制器4。另外，表示图11、图14、图16中示出的控制器、组的数量的M的值可以分别不同。

该处理中，通信控制器3或多个群管理控制器4中，存储了固件映像31的一个是主控制器30，其他是副控制器40。然后，主控制器30将包括发送顺序的数据包50发送至副控制器40，接收了数据包50的副控制器40对固件映像31进行更新。通过这样使通信控制器3、与多个群管理控制器4成为主控制器30和副控制器40的关系，能够不限定于一个控制器地进行副控制器40的固件映像31的更新处理。

于是，设想从上级的通信控制器3将固件映像31下载至群管理控制器4的情况。该情况下，是通信控制器3作为主控制器30、多个群管理控制器4作为副控制器40的结构。

另外，存在任意的群管理控制器4经由通信控制器3下载固件映像31的情况。该情况下，是一个群管理控制器4作为主控制器30、除此以外的群管理控制器4和通信控制器3作为副控制器40的结构。采用该结构的情况下，一个群管理控制器4也能够对通信控制器3和其他群管理控制器4发送固件映像31。

另外，与维护终端19连接并下载了固件映像31的控制器20作为主控制器30的情况下，与该控制器20连接至相同的段的其他控制器20作为副控制器40。此处，作为下载了固件映像31的控制器20，例如设想为通信控制器3。

＜与群管理控制器的分配数相应的顺序的生成处理＞

接着，对于通信控制器3的顺序生成部34基于作为运行状态之一的群管理控制器4的分配处理的结果即对多个群管理控制器4的呼梯的分配次数的状况、即对电梯15的呼梯的分配数和分配处理状态生成发送顺序53的数据的处理，使用图17进行说明。因此，此处生成与由对群管理控制器4的呼梯的分配次数的状况决定的处理负载相应的发送顺序。

图17是表示与对电梯15的呼梯的分配数和分配处理状态相应的顺序的生成处理的例子的流程图。

首先，通信控制器3的运行状态获取部33从各群管理控制器4获取呼梯的分配数和分配处理状态(S81)。接着，运行状态获取部33确认是否从全部群管理控制器4获取了呼梯的分配数和分配处理状态(S82)。尚未从全部群管理控制器4获取的情况下(S82的否)，运行状态获取部33返回步骤S81，反复进行呼梯的分配数和分配处理状态的获取。

另一方面，已对于全部群管理控制器4获取的情况下(S82的是)，通信控制器3的顺序生成部34与运行状态获取部33获取的分配数和分配处理状态相应地排列群管理控制器4的发送顺序并生成发送顺序53的数据(S83)，结束本处理。

发送顺序的排列按照是否发生呼梯分配处理和分配数的升序进行。呼梯分配处理已完成的群管理控制器4在处理负载上存在余力。即使是呼梯分配处理已完成的群管理控制器4，呼梯的分配数较多的群管理控制器4能够分配的选项较少，所以群管理控制器4的处理负载增大的可能性较低。即，因为被分配呼梯的选项较少，所以群管理控制器4的处理负载增加的可能性较低。

另一方面，呼梯分配处理中的群管理控制器4与分配处理已完成的群管理控制器4相比处理负载更大。即使是呼梯分配处理中的群管理控制器4，已经被分配的呼梯的分配数较少的群管理控制器4此后被分配呼梯的选项较多，所以群管理控制器4的处理负载增加的可能性较高。

因此，顺序生成部34通过与是否呼梯分配处理这一点、以及呼梯的分配数的大小相应地生成发送顺序53的数据，能够按照将分配处理已完成的群管理控制器4设为最先、将正在处理中并且分配数较少的处理负载大的群管理控制器4设为最后的顺序应用固件映像31。

通过设为这样的与运行信息相应的顺序，能够从处理存在余力的群管理控制器4起对固件映像31效率良好地进行更新。因此，通信控制器3能够为了对群管理控制器4应用更新后的新的固件映像31而立即使群管理控制器4重新启动的可能性提高。

＜各控制器的重新启动的处理＞

接着，对于群管理控制器4、电梯控制器5、楼层控制器11分别为了应用固件映像31的重新启动的处理，使用图18～图20进行说明。

＜群管理控制器的重新启动(已完成分配)＞

首先，对于群管理控制器4与作为运行状态之一的呼梯分配处理状态相应地为了应用更新的固件映像31而重新启动的处理，使用图18进行说明。

图18是表示群管理控制器4对为了应用固件映像31的重新启动进行判断的处理的例子的流程图。该处理中，在对于群管理控制器4的固件映像31的更新已完成的时间点没有执行呼梯分配处理的情况下，固件映像31的更新已完成的群管理控制器4的映像构建部45实施重新启动。因此，群管理控制器4在群管理控制器4管理的电梯15中没有使用者的时段重新启动，不会对使用者产生不便。

首先，群管理控制器4获取呼梯分配处理的执行状态(S91)。

群管理控制器4确认是否正在执行呼梯分配处理(S92)。如果正在执行呼梯分配处理(S92的是)，则不执行重新启动，结束本处理。

一定时间后，群管理控制器4从步骤S91起重新开始处理。另一方面，如果并非正在执行呼梯分配处理、即呼梯分配处理已完成、呼梯已完成分配(S92的否)，则使群管理控制器4重新启动(S93)，结束本处理。

通过这样的处理，群管理控制器4在对固件映像31进行更新时，无需确保如维护模式这样特别的模式或作业时间，就能够进行为了应用新的固件映像31的重新启动。

＜电梯控制器的重新启动(在下一次到达前预约停止模式)＞

接着，对于电梯控制器5与作为运行状态之一的目的地楼层信息相应地、为了应用更新后的固件映像31而重新启动的处理，使用图19进行说明。

图19是表示电梯控制器5对为了应用固件映像31的重新启动进行判断的处理的例子的流程图。该处理中，电梯控制器5的映像构建部45在电梯控制器5的固件映像31的更新已完成的时间点已登记了电梯15的目的地楼层的情况下，暂时停止电梯控制器5的新的呼梯的受理。然后，电梯控制器5的映像构建部45在轿厢到达目的地楼层之后，已确认轿厢的安全状态的情况下，实施电梯控制器5的重新启动。因此，在没有使用者的电梯15中使电梯控制器5重新启动，不会对使用者产生不便。

首先，电梯控制器5获取作为运行状态之一的目的地楼层信息(S101)。接着，电梯控制器5对目的地楼层信息进行判断(S102)。登记了多个目的地楼层的情况下，因为需要使电梯15继续运行所以不能进行重新启动。另一方面，对于目的地楼层登记了一个楼层、或者没有登记目的地楼层的情况下(S102的否)，电梯控制器5为了不会新发生呼梯登记而将呼梯登记屏蔽(S103)。于是，电梯控制器5转移至作为不受理新的呼梯的模式，并且设为作为轿厢7到达目的地楼层时能够重新启动的运行模式的、例如维护模式地进行处理。

接着，电梯控制器5确认轿厢7是否已到达目的地楼层(S104)，判断轿厢7是否已到达目的地楼层(S105)。如果轿厢7尚未到达目的地楼层(S105的否)，则电梯控制器5返回步骤S104继续进行轿厢7的到达确认。

另一方面，轿厢7已到达目的地楼层的情况下(S105的是)，电梯控制器5获取轿厢状态(S106)。接着，电梯控制器5判断获取的轿厢状态至少对于乘客而言是否安全状态(S107)。

轿厢7中没有乘客搭乘并且门关闭的状态是最安全的状态。判断为并非安全状态的情况下(S107的否)，电梯控制器5结束本处理。一定时间后，电梯控制器5从步骤S101起重新开始处理。另一方面，判断为安全状态的情况下(S107的是)，电梯控制器5执行自身的重新启动(S108)，结束本处理。

通过这样的处理，电梯控制器5在对固件映像31进行更新时，无需确保维护模式这样特别的模式或作业时间，就能够进行为了应用新的固件映像31的重新启动。

＜楼层控制器的重新启动(确认呼梯登记)＞

接着，对于楼层控制器11与作为运行状态之一的上下呼梯的登记相应地为了应用更新后的固件映像31而重新启动的处理，使用图20进行说明。此处，楼层控制器11的映像构建部45在楼层控制器11的固件映像31的更新完成的时间点确认呼梯的登记，在没有登记呼梯的情况下，实施楼层控制器11的重新启动。因此，在没有使用者的楼层中使楼层控制器11重新启动，不会对使用者产生不便。

图20是表示楼层控制器11为了应用固件映像31而重新启动的处理的例子的流程图。

首先，楼层控制器11获取上下呼梯的登记的状态(S111)。

接着，楼层控制器11判断是否存在上下呼梯的登记(S112)。存在上下呼梯的登记的情况下(S112的是)，因为电梯15的运转继续进行所以不能进行重新启动。从而，本处理在此处结束，一定时间后，楼层控制器11从步骤S111起重新开始处理。

另一方面，不存在上下呼梯的登记的情况下(S112的否)，与使该楼层的楼层控制器11从电梯15的运行状态暂时分离的状态相当，所以楼层控制器11执行重新启动(S113)，结束本处理。

通过这样的处理，楼层控制器11在对固件映像31进行更新时，无需确保维护模式这样特别的模式或作业时间，就能够进行为了应用新的固件映像31的重新启动。

另外，本发明不限定于上述各实施方式，只要不脱离要求的权利范围中记载的本发明的主旨就可以采用其他各种应用例、变形例。

例如，上述各实施方式为了易于理解地说明本发明而详细且具体地说明了装置和***的结构，并不限定于必须具备说明的全部结构。另外，能够将此处说明的实施方式的结构的一部分置换为其他实施方式的结构，进而也能够在某个实施方式的结构上添加其他实施方式的结构。另外，对于各实施方式的结构的一部分，也能够追加、删除、置换其他结构。

另外，控制线和信息线示出了认为说明上必要的，并不一定示出了产品上全部的控制线和信息线。实际上也可以认为几乎全部结构都相互连接。

附图标记说明

1…中心，3…通信控制器，4…群管理控制器，5…电梯控制器，10…轿厢控制器，11…楼层控制器，18…电梯组，19…维护终端，20…控制器，30…主控制器，31…固件映像，32…映像分割部，33…运行状态获取部，34…顺序生成部，35…数据包生成部，36…主通信部，40…副控制器，41…副通信部，42…数据包解释部，43…发送目的地提取部，44…数据包生成部，45…映像构建部，50…数据包，100…电梯***，200…数据包通信***。

Claims (15)

1.一种电梯***，具有发送固件的主控制器和接收所述固件来更新所述固件的副控制器，其特征在于：

所述主控制器基于所述电梯的运行状态来生成对多个所述副控制器发送所述固件的发送顺序，对于所述发送顺序优先的所述副控制器，发送包括所述固件和所述发送顺序的第一发送数据，

所述发送顺序优先的所述副控制器，从所述主控制器接收所述第一发送数据来进行所述固件的更新，并对所述发送顺序第二优先的所述副控制器发送所述第一发送数据。

2.如权利要求1所述的电梯***，其特征在于：

所述主控制器包括：

获取电梯的运行状态的运行状态获取部；

顺序生成部，其基于所述运行状态生成作为所述固件的发送目的地的所述副控制器的发送顺序；

分割所述固件的固件分割部；

第一发送数据生成部，其生成用于按照所述发送顺序对所述副控制器发送所述固件的第一发送数据；和

对所述发送顺序最靠前的所述副控制器发送所述第一发送数据的第一通信部，

所述第一发送数据生成部生成所述第一发送数据，所述第一发送数据包括用于识别所述主控制器的信息、用于识别所述副控制器的信息、所述发送顺序、分割后的所述固件的构建顺序、以及分割后的所述固件。

3.如权利要求2所述的电梯***，其特征在于：

所述副控制器包括：

第二通信部，其从所述主控制器或者作为所述第一发送数据的发送源的所述副控制器接收所述第一发送数据；

解释所述第一发送数据的数据解释部；

固件构建部，其将所述数据解释部进行了解释的分割后的所述固件按照所述构建顺序构建为原本的所述固件；

发送目的地提取部，其基于所述数据解释部进行了解释所得到的所述发送顺序，提取作为所述第一发送数据的下一个发送目的地的所述副控制器；和

第二发送数据生成部，其生成用于对作为所述第一发送数据的下一个发送目的地的所述副控制器发送所述固件的第二发送数据，

所述第二通信部对作为下一个发送目的地的所述副控制器发送所述第二发送数据。

4.如权利要求3所述的电梯***，其特征在于：

在所述固件构建部进行所述固件的更新的途中发生了异常的情况下，所述第二通信部按照与所述发送顺序相反的顺序对所述主控制器发送包括关于所述异常的信息的数据。

5.如权利要求4所述的电梯***，其特征在于：

所述固件构建部在所述固件的更新途中发生了异常的情况下，删除所述固件构建部构建了的所述固件。

6.如权利要求3所述的电梯***，其特征在于：

所述第二通信部，在从作为所述第一发送数据的下一个发送目的地的所述副控制器接收了包括关于在所述固件的更新途中发生的异常的信息的数据的情况下，跳过发送包括关于所述异常的信息的数据的所述副控制器，而对后续的所述副控制器发送所述第二发送数据。

7.如权利要求3所述的电梯***，其特征在于，包括：

控制所述电梯的动作的电梯控制器；和

设置在所述电梯进行升降的各个楼层的多个楼层控制器，其对所述电梯控制器通知所述楼层的状况，

在将所述电梯控制器和多个楼层控制器中的存储有所述固件的一个控制器作为主控制器、其他控制器作为副控制器的情况下，所述主控制器对所述副控制器发送包括所述发送顺序的所述第一发送数据，接收了所述第一发送数据的所述副控制器更新所述固件。

8.如权利要求7所述的电梯***，其特征在于：

所述主控制器基于作为所述运行状态获取的各楼层的呼梯登记的状况来生成所述发送顺序，并基于所述楼层的停留人数的状况来重新排列所述发送顺序。

9.如权利要求7所述的电梯***，其特征在于：

所述固件构建部在所述楼层控制器的固件的更新完成的时刻确认呼梯登记，在没有登记呼梯的情况下实施所述楼层控制器的重新启动。

10.如权利要求3所述的电梯***，其特征在于，包括：

对控制所述电梯的动作的多个电梯控制器的动作进行控制的群管理控制器；和

多个电梯控制器，

在将所述群管理控制器和多个电梯控制器中的存储有所述固件的一个控制器作为主控制器、其他控制器作为副控制器的情况下，所述主控制器对所述副控制器发送包括所述发送顺序的所述第一发送数据，接收了所述第一发送数据的所述副控制器更新所述固件。

11.如权利要求10所述的电梯***，其特征在于：

所述顺序生成部基于作为所述运行状态获取的对多个所述电梯的呼梯分配的状况来生成所述发送顺序。

12.如权利要求10所述的电梯***，其特征在于：

所述固件构建部在所述电梯控制器的所述固件的更新完成的时刻登记了所述电梯的目的地楼层的情况下，暂时停止所述电梯控制器受理新的呼梯，在轿厢到达所述目的地楼层之后确认了所述轿厢的安全状态的情况下，所述电梯控制器实施重新启动。

13.如权利要求3所述的电梯***，其特征在于，包括：

控制对于控制多个电梯控制器的动作的多个群管理控制器的通信的通信控制器；和

多个所述群管理控制器，

在将所述通信控制器和多个所述群管理控制器中的存储有所述固件的一个控制器作为主控制器、其他控制器作为副控制器的情况下，所述主控制器对所述副控制器发送包括所述发送顺序的所述第一发送数据，接收了所述第一发送数据的所述副控制器更新所述固件。

14.如权利要求13所述的电梯***，其特征在于：

所述顺序生成部基于作为所述运行状态获取的对多个所述群管理控制器的呼梯的分配次数的状况来生成所述发送顺序，

所述固件构建部在对所述群管理控制器的所述固件的更新完成的时刻没有执行呼梯分配处理的情况下，所述固件的更新已完成的群管理控制器实施重新启动。

15.一种在具有发送固件的主控制器和接收所述固件来更新所述固件的副控制器的电梯***中执行的固件发送方法，其特征在于，包括：

所述主控制器基于所述电梯的运行状态来生成对多个所述副控制器发送所述固件的发送顺序，对于所述发送顺序优先的所述副控制器发送包括所述固件和所述发送顺序的第一发送数据的处理；和

所述发送顺序优先的所述副控制器从所述主控制器接收所述第一发送数据来进行所述固件的更新，并对所述发送顺序第二优先的所述副控制器发送所述第一发送数据的处理。