CN110383249B

CN110383249B - 软件更新管理系统和软件更新方法

Info

Publication number: CN110383249B
Application number: CN201780088075.1A
Authority: CN
Inventors: 佐藤健二; 妻鹿利宏; 南田宗佑; 川崎仁; 太田惠大; 浮穴朋兴
Original assignee: Mitsubishi Electric Building Solutions Corp
Current assignee: Mitsubishi Electric Building Solutions Corp
Priority date: 2017-03-09
Filing date: 2017-07-28
Publication date: 2023-07-07
Anticipated expiration: 2037-07-28
Also published as: JP6664343B2; WO2018163461A1; CN110383249A; JP2018147413A

Abstract

还考虑机器设备的控制调度中未出现的控制来进行软件的更新。具有：控制调度信息存储部(38)，其存储定义了楼宇机器(30)的控制调度的控制调度信息；更新请求受理部(31)，其受理在楼宇机器(30)中进行动作的软件的更新请求信息；更新判定部(33)，其判定可否进行软件的更新；以及软件更新部(34)，其进行软件的更新。更新判定部(33)参照状态监视部(32)取得的楼宇机器(30)的负荷的状态信息，计算达到更新预定时间的软件的更新处理对控制调度信息中定义了调度的控制和控制调度信息中未定义调度的控制造成的影响度，在计算出的影响度为阈值以上的情况下，不指示软件更新部(34)进行该软件的更新。

Description

软件更新管理系统和软件更新方法

技术领域

本发明涉及软件更新管理系统和程序，特别涉及在机器设备中进行动作的软件的更新。

背景技术

对作为维护对象的楼宇的业主等顾客使用的平板或智能手机等终端发布应用，向顾客提供与顾客楼宇的机器设备相关联的服务。为了使顾客使用已发布的应用而能够正常利用服务，在楼宇的机器设备中进行动作的软件的版本需要对应于已发布的应用。在不对应的情况下，需要更新或新安装机器设备的软件。在以后的说明中，将更新和新安装统一称作“更新”。

以往，提出了参照更新的实绩或楼宇机器的运用调度来生成机器设备(控制器)的软件的更新调度的技术(例如专利文献1)。

现有技术文献

专利文献

专利文献1：日本特开2015-191502号公报

专利文献2：日本特开2009-157597号公报

专利文献3：日本特开2009-286600号公报

专利文献4：日本特开2008-186392号公报

专利文献5：日本特开2009-169524号公报

专利文献6：日本特开2011-113391号公报

专利文献7：日本特开2008-152332号公报

专利文献8：日本特开2001-067225号公报

发明内容

发明要解决的课题

但是，在顾客无法利用上述服务的情况下，顾客无法判断可以对哪个机器设备的软件进行更新，以及可以在哪个时机进行更新。楼宇管理公司对机器设备的软件及其更新进行管理，但是，软件的更新可能对其他系统(例如更新对象为空调机器的情况下的进出管理系统)或其他顾客(例如楼宇为租户楼宇的情况下的其他租户)对机器设备的控制造成影响。因此，例如，期望在不怎么利用机器设备的时段等适当的时机进行软件的更新。

以往，参照软件的更新实绩或机器设备的控制调度求出不对机器设备的控制造成影响的时段，在该时段进行软件的更新。但是，在用于使机器设备进行动作的控制处理中，存在未作为控制调度设定的控制(例如以顾客操作或环境变化为触发而执行的控制)或楼宇机器的内部处理(例如数据累计处理)等，但是，以往没有考虑对软件的更新实绩或机器设备的控制调度中未出现的控制造成的影响。

本发明的目的在于，还考虑机器设备的控制调度中未出现的控制来进行软件的更新。

用于解决课题的手段

本发明的软件更新管理系统具有：控制调度信息存储单元，其存储定义了机器设备的控制的调度的控制调度信息；受理单元，其受理包含有在所述机器设备中进行动作的软件的更新预定时间和更新所要时间的更新请求信息；状态信息取得单元，其取得表示对所述机器设备施加的负荷的状态的状态信息；更新判定单元，其判定可否进行软件的更新；以及更新单元，其根据来自所述更新判定单元的指示进行软件的更新，所述更新判定单元包含影响度计算部，该影响度计算部参照所述状态信息，计算表示影响的程度的影响度，达到更新预定时间的软件的更新处理不仅对所述控制调度信息中定义了调度的控制造成所述影响，而且对所述控制调度信息中未定义调度的控制也造成所述影响，在计算出的影响度为规定的阈值以上的情况下，所述更新判定单元不指示所述更新单元进行该软件的更新。

此外，在所述控制调度信息中预先设定有针对所述机器设备的各控制的优先级，所述更新判定单元包含优先级设定部，该优先级设定部针对成为更新预定时间也未被执行更新的软件，设定与从更新预定时间起的经过时间对应的优先级，即使该软件的影响度为阈值以上，在该软件的优先级高于在要执行该软件的更新时反复执行的控制的优先级的情况下，所述更新判定单元也指示所述更新单元进行该软件的更新。

此外，所述软件更新管理系统具有负荷模型存储单元，该负荷模型存储单元存储定义了对所述机器设备施加的负荷的时序变化的负荷模型，即使该软件的影响度为阈值以上，在通过参照所述负荷模型而判断为对所述机器设备施加的负荷今后上升的情况下，所述更新判定单元也指示所述更新单元进行该软件的更新。

本发明的程序使能够访问存储定义了机器设备的控制调度的控制调度信息的控制调度信息存储单元的计算机作为以下单元发挥功能：受理单元，其受理包含在所述机器设备中进行动作的软件的更新预定时间和更新所要时间的更新请求信息；状态信息取得单元，其取得表示对所述机器设备施加的负荷的状态的状态信息；更新判定单元，其判定可否进行软件的更新；以及更新单元，其根据来自所述更新判定单元的指示进行软件的更新。

所述更新判定单元包含影响度计算部，该影响度计算部参照所述状态信息，计算表示影响的程度的影响度，达到更新预定时间的软件的更新处理不仅对所述控制调度信息中定义了调度的控制造成所述影响，而且对所述控制调度信息中未定义调度的控制也造成所述影响，在计算出的影响度为规定的阈值以上的情况下，所述更新判定单元不指示所述更新单元进行该软件的更新。

发明效果

根据本发明，能够还考虑机器设备的控制调度中未出现的控制来进行软件的更新。

此外，在等待软件的更新以不会对控制的执行造成障碍的情况下，在从更新预定日期时间起经过的时间较长的情况下，也能够进行软件的更新。

此外，即使在对控制设备施加的负荷较高而对控制的执行造成障碍的状态下，如果今后对控制设备施加的负荷进一步上升，则也能够在当前时点进行软件的更新。

附图说明

图1是示出本发明的软件更新管理系统的一个实施方式的整体结构图。

图2是搭载于实施方式1中的楼宇机器的计算机的硬件结构图。

图3是实施方式1中的楼宇机器的结构框图。

图4是示出实施方式1中的更新请求信息存储部中登记的更新请求信息的数据结构的一例的图。

图5是示出实施方式1中的控制调度信息存储部中登记的控制调度信息的数据结构的一例的图。

图6是示出实施方式1中的软件更新处理的流程图。

图7是示出实施方式1中取得的状态信息的数据结构的一例的图。

图8是实施方式2中的楼宇机器的结构框图。

图9是示出实施方式2中的更新请求信息存储部中登记的更新请求信息的数据结构的一例的图。

图10是示出实施方式2中的控制调度信息存储部中登记的控制调度信息的数据结构的一例的图。

图11是示出实施方式2中的软件更新处理的流程图。

图12是实施方式3中的楼宇机器的结构框图。

图13是示出实施方式3中的软件更新处理的流程图。

具体实施方式

下面，根据附图对本发明的优选实施方式进行说明。

实施方式1

图1是示出本发明的软件更新管理系统的一个实施方式的整体结构图。在图1中示出远程监视中心1、顾客事务所2和顾客楼宇3。顾客事务所2是顾客楼宇3的业主等顾客的事务所，设置有经由公共线路或互联网等顾客用网络4而与远程监视中心1进行通信的顾客终端20。顾客终端20是顾客使用的个人计算机(PC)、智能手机或平板等终端。顾客楼宇3是顾客拥有的楼宇，设置有作为软件更新对象的1个或多个机器设备(以下为“楼宇机器”)30。楼宇机器30经由公共线路或互联网等机器用网络5而与远程监视中心1进行通信。另外，在顾客楼宇3中设置有1个或多个楼宇机器30，但是，各楼宇机器30均具有后述结构即可，因此，为了简便，在图1中仅图示1台。

远程监视中心1是楼宇机器维护公司的设施，远程监视设置于顾客楼宇3中的楼宇机器30。此外，通过对顾客终端20发布应用，向顾客提供与顾客拥有的顾客楼宇3的楼宇机器30的利用相关联的服务。

远程监视中心1具有通过内部网16连接管理终端11、软件管理服务器12、顾客信息管理服务器13、顾客服务服务器14和楼宇机器管理装置15而成的结构。管理终端11由在远程监视中心1中对面向顾客终端的应用和面向楼宇机器的软件进行管理的管理者使用的PC等构成，用于软件和各种信息的管理。软件管理服务器12是对面向顾客终端的应用和面向楼宇机器的软件进行保持管理的服务器计算机。顾客信息管理服务器13是针对顾客楼宇3的楼宇机器30对包含配置和软件版本等的结构信息进行保持管理的服务器计算机。顾客服务服务器14是向顾客提供服务的服务器计算机。因此，顾客服务服务器14根据来自顾客的请求将面向顾客终端的应用下载到顾客终端20。此外，顾客服务服务器14请求楼宇机器管理装置15更新楼宇机器30中的软件，进而在从楼宇机器管理装置15接收到软件已被更新的通知时，向顾客通知已能够利用所下载的面向顾客终端的应用。楼宇机器管理装置15是在楼宇机器30的管理中使用的服务器计算机。具体而言，执行楼宇机器30的控制和状态监视。此外，根据软件的更新请求对楼宇机器30自身执行的软件的更新进行管理。

图2是本实施方式中的搭载于楼宇机器30的计算机的硬件结构图。在本实施方式中，假设能够自己更新软件且具有执行能力的控制器。控制器是进行连接着的空调等各种机器(未图示)的动作控制的机器设备。搭载于控制器的计算机能够通过以往存在的通用的硬件结构实现。即，如图2所示，计算机构成为将CPU41、ROM42、RAM43、硬盘驱动器(HDD)44、作为通信单元设置的网络接口(IF)45与内部总线46连接。

图3是本实施方式中的楼宇机器30的结构框图。另外，本实施方式的说明中不使用的结构要素从附图中省略。本实施方式中的楼宇机器30具有更新请求受理部31、状态监视部32、更新判定部33、软件更新部34、控制部35、软件存储部36、更新请求信息存储部37和控制调度信息存储部38。更新请求受理部31从远程监视中心1受理在楼宇机器30中进行动作的软件的更新请求信息。状态监视部32监视对楼宇机器30施加的负荷的状态，将表示该状态的状态信息转交给更新判定部33。更新判定部33根据更新请求受理部31受理的更新请求，判定是否能够进行所请求的软件的更新。然后，在判定为能够更新时，指示软件更新部34进行软件的更新。本实施方式中的更新请求受理部31包含有影响度计算部331。影响度计算部331参照状态信息，计算表示影响的程度的影响度，达到更新预定时间的软件的更新处理不仅对控制调度信息中定义了调度的控制造成所述影响，而且对控制调度信息中未定义调度的控制也造成所述影响。软件更新部34根据来自更新判定部33的指示进行软件的更新。控制部35与各结构要素31～34协作来控制软件的更新处理。在软件存储部36中蓄积有更新对象的软件。

图4是示出本实施方式中的更新请求信息存储部37中登记的更新请求信息的数据结构的一例的图。在更新请求信息存储部37中登记有由更新请求受理部31取得的更新请求信息，在由软件更新部34执行更新后将其删除。更新请求信息包含U-ID、楼宇ID、机器ID、软件名、版本、所要时间和更新请求日期时间。U-ID是更新请求信息(记录)的识别信息。楼宇ID是受理了更新请求信息的顾客楼宇3的识别信息。机器ID是作为软件更新对象的楼宇机器30的识别信息。在本实施方式中，按照每个楼宇机器30保持更新请求信息，因此，在楼宇ID和机器ID中分别设定有相同的识别信息。软件名是作为确定更新对象软件的信息的名称，版本表示更新后的软件的版本。所要时间是该软件的更新所需要的时间。更新请求日期时间是开始执行该软件的更新处理的预定日期时间。

图5是示出本实施方式中的控制调度信息存储部38中登记的控制调度信息的数据结构的一例的图。在控制调度信息存储部38中登记有预先定义了针对楼宇机器30进行的控制调度的更新请求信息。动作控制部(未图示)按照该控制调度对楼宇机器30或与楼宇机器30连接的空调等机器设备的动作进行控制。控制调度信息包含SC-ID、楼宇ID、机器ID、控制内容、设定值、开始日期时间和结束日期时间。SC-ID是控制调度信息(记录)的识别信息。楼宇ID和机器ID如更新请求信息中说明的那样。控制内容是确定要实施的控制的内容的名称。在设定值中设定有实施该控制时的具体设定值。开始日期时间和结束日期时间是指定实施控制的时间范围的信息，设定该控制的开始和结束。

楼宇机器30中的各结构要素31～35通过搭载于楼宇机器30的计算机与搭载于计算机的CPU41中进行动作的程序的协调动作实现。此外，各存储部36～38通过搭载于楼宇机器30的HDD44实现。或者，也可以利用RAM43或经由网络利用位于外部的存储单元。

此外，本实施方式中使用的程序当然能够通过通信单元提供，还能够存储在CD-ROM或USB存储器等计算机能读取的记录介质中进行提供。从通信单元或记录介质提供的程序安装于计算机，计算机的CPU依次执行程序，由此实现各种处理。

在面向顾客终端的应用或面向楼宇机器的软件被更新时，管理者将使用管理终端11更新后的软件、以及表示面向顾客终端的应用与面向楼宇机器的软件的版本的对应关系的对应信息登记到软件管理服务器12中。顾客操作顾客终端20，从顾客服务服务器14通过下载取得面向顾客终端的应用。顾客服务服务器14通过参照软件管理服务器12中登记的对应信息和顾客信息管理服务器13中登记的顾客信息，在识别出与该顾客新取得的面向顾客终端的应用对应的版本的面向楼宇机器的软件未安装在该顾客的顾客楼宇3的楼宇机器30中时，请求楼宇机器管理装置15进行楼宇机器30的软件的更新。楼宇机器管理装置15根据该请求向楼宇机器30发送更新请求信息，由此指示进行软件的更新。

在从远程监视中心1发送来更新请求信息时，更新请求受理部31取得该信息，将其登记到更新请求信息存储部37中，由此受理软件的更新请求。

接着，使用图6所示的流程图对本实施方式中的软件更新处理进行说明。

更新判定部33从更新请求信息存储部37中，从更新请求信息中读出1个记录(步骤101)。另外，这里，着眼于读出的1个更新请求信息进行说明。针对其他更新请求信息，也同样从更新请求信息存储部37读出并进行后述处理。更新判定部33还从控制调度信息存储部38中读出控制调度信息(步骤102)。

进行等待直到成为在读出的更新请求信息中作为更新对象的软件的更新预定日期时间为止(步骤103：否)，在成为该更新预定日期时间后(步骤103：是)，更新判定部33从状态监视部32取得状态信息(步骤104)。另外，在本实施方式中，按照上述这种步骤进行处理，但是，也可以在步骤101中使更新判定部33始终对更新请求信息的更新预定日期时间和当前时刻进行对比，在达到更新预定日期时间的时点读出相应的更新请求信息。

图7是示出本实施方式中的状态信息的数据结构例的图。状态信息包含S-ID、楼宇ID、机器ID、监视项目名、状态和取得日期时间。S-ID是状态信息(记录)的识别信息。楼宇ID和机器ID如更新请求信息中说明的那样。监视项目名是表示要监视的项目的名称。状态是该监视项目中的当前时点的状态。第1个记录的状态信息示出CPU负荷率为70％。取得日期时间是取得负荷状态的日期时间。

接着，影响度计算部331针对达到更新预定日期时间的软件计算影响度(步骤105)。影响度是客观地通过数值表示由于执行达到更新预定日期时间的软件的更新处理而对楼宇机器30造成的影响的指标。在本实施方式中，如下计算影响度。首先，为了简化说明，着眼于CPU负荷率进行说明。

在本实施方式中，为了判别有无影响度而预先设定阈值。例如，设在针对CPU负荷率的阈值中设定80％。这里，设根据状态信息检测到的CPU负荷率为70％。该情况下的影响度为70％，低于阈值(80％)(步骤106：否)，因此，更新判定部33指示软件更新部34进行该软件的更新。软件更新部34根据该指示，从远程监视中心1取得新版本的软件，对该软件进行更新(步骤107)。

另一方面，在设根据状态信息检测到的CPU负荷率(影响度)为90％时，成为阈值(80％)以上(步骤106：是)，因此，更新判定部33不指示软件更新部34进行该软件的更新而返回步骤104。即，反复进行步骤104～106，直到影响度低于阈值为止。

在以上的说明中，为了简化说明，着眼于CPU负荷率进行了说明，但是，作为表示楼宇机器30的负荷的信息，除此之外，还存在存储器使用率等各种信息(监视项目)。因此，在本实施方式中，通过计算来算出影响度。即，当设影响度为I时，通过下式计算影响度。

I＝a(tb-ta)+bLa

这里，tb是更新请求信息中设定的所要时间，ta是从控制调度信息的开始日期时间得到的时间，即针对某个控制从当前时刻到下次执行该控制的时间(开始日期时间)为止的时间。这里所说的“某个控制”是指在要执行该软件的更新处理的情况下反复执行的控制。这是因为，控制和软件的更新处理均使用(消耗)楼宇机器30的资源，因此，当在更新预定日期时间执行软件的更新处理时，可能对反复执行的现有的控制造成影响。La是通过规定的计算式对根据取得的状态信息在当前时点对楼宇机器30施加的负荷进行数值化而得到的负荷信息。a和b是系数，按照每个楼宇机器30或楼宇机器30的每个种类(空调、进出系统等)适当设定。

在上述计算式中，(tb-ta)表示是否能够在不执行控制调度信息中定义的控制的期间内执行软件的更新处理。如果软件更新的所要时间tb比不执行控制的空闲时间ta长，则相应地对控制的执行造成影响。

此外，在负荷信息La中包含基于控制调度中未定义的控制(例如以顾客操作或环境变化为触发而执行的控制)或楼宇机器的内部处理(例如数据累计处理)等的使用而对楼宇机器30施加的负荷。通过加上该负荷信息La来计算影响度，在判定可否进行软件的更新时，能够考虑软件的更新实绩或机器设备的控制调度中未出现的控制引起的负荷。虽然没有执行控制调度中定义的控制，但是如果负荷信息La所示的值相对较大，则能够估计为有可能执行了控制调度中未定义的控制。即，当开始进行软件的更新时，可能对控制调度中未定义的控制的执行造成影响。

在上述说明中，使用CPU负荷率简单进行了说明，但是，更新判定部33对在影响度计算部331中通过上述计算式计算出的影响度和规定的阈值进行比较，由此，如上述说明的那样判定可否进行软件的更新。另外，上述计算式只是一例，不需要限定于此。

当计算出的影响度低于阈值时(步骤106：否)，如上所述，通过更新判定部33的指示来进行软件的更新(步骤107)。

另一方面，在影响度为阈值以上的情况下(步骤106：是)，反复进行步骤104～106。但是，可认为楼宇机器30的负荷最终会降低，影响度最终会低于阈值。也许更新预定日期时间已过，但是能够在不对楼宇机器30的控制的执行造成影响的时机执行软件的更新。

如以上说明的那样，根据本实施方式，通过考虑对楼宇机器30施加的负荷，能够不仅考虑软件的更新处理对控制调度信息中定义的控制造成的影响，而且考虑对控制调度信息中未定义的控制造成的影响，控制执行软件的更新。即，根据本实施方式，能够以不对楼宇机器30中的动作、运用等造成影响的方式对软件进行更新。

当软件的更新结束时，在控制部35或基于控制部35的控制下，通过软件更新部34从更新请求信息存储部37中删除与该软件对应的更新请求信息。然后，经由远程监视中心1向顾客通知软件已被更新，由此，顾客得知能够利用面向顾客终端的应用。这样，根据本实施方式，顾客能够接受服务的提供而不用考虑楼宇机器30中应该更新的软件或软件的更新时机。

另外，在本实施方式中，从更新请求信息存储部37中删除与更新结束的软件对应的更新请求信息，但是，也可以不删除，而与该更新请求信息对应地记录表示更新结束的标志信息或更新结束日期时间。

实施方式2

图8是本实施方式中的楼宇机器的结构框图。对与实施方式1(图1)相同的结构要素标注相同标号并省略说明。在本实施方式中，在实施方式1所示的更新判定部33中追加优先级设定部332。优先级设定部332针对成为更新预定时间也未执行更新的软件，设定与从更新预定时间起的经过时间对应的优先级。另外，楼宇机器30的硬件结构可以与实施方式1相同。

图9是示出本实施方式中的更新请求信息存储部37中登记的更新请求信息的数据结构的一例的图。在本实施方式中的更新请求信息中，在实施方式1(图4)所示的数据结构中追加设定由优先级设定部332设定并更新的优先级。

图10是示出本实施方式中的控制调度信息存储部38中登记的控制调度信息的数据结构的一例的图。在本实施方式中的控制调度信息中，在实施方式1(图5)所示的数据结构中预先设定有设定度。控制调度信息中包含的优先级是与控制分别对应地设定的固定值。越是希望没有延迟地按照调度执行的控制，则设定值越高的优先级。

接着，使用图11所示的流程图对本实施方式中的软件更新处理进行说明。另外，对与实施方式1相同的处理步骤标注相同的步骤编号并适当省略说明。

如上所述，更新判定部33在判定可否进行软件的更新时，参照楼宇机器30的负荷状态计算影响度(步骤101～105)。然后，当计算出的影响度低于阈值时(步骤106：否)，与实施方式1同样，通过更新判定部33的指示来进行软件的更新(步骤107)。

另一方面，在影响度为阈值以上的情况下(步骤106：是)，本实施方式中的优先级设定部332对该软件设定优先级(步骤201)。更加详细地说明时，在各软件中设定0作为优先级的初始值，每当从该软件的更新请求日期时间起的经过时间超过规定的阈值Ts时，逐一提高优先级。例如，在设阈值Ts为5分钟的情况下，在从更新请求日期时间起经过了5分钟时更新为1，在经过了10分钟时更新为2，优先级随着时间的经过而被更新为较高的值。

当设定优先级时，更新判定部33参照软件的所要时间以及控制调度信息的开始日期时间和结束日期时间，从控制调度信息中定义的控制中，在现在要执行软件的更新的情况下，提取与软件的更新处理重复执行的控制。然后，对软件的优先级和提取出的1个或多个控制的优先级进行比较，如果软件的优先级高于全部控制的优先级(步骤202：否)，则更新判定部33对软件更新部34进行指示，由此更新软件(步骤107)。

另一方面，如果软件的优先级为任意控制的优先级以下(步骤202：是)，则不进行软件的更新指示而返回步骤104。由此，有可能反复执行步骤104～202的处理，但是，在步骤201中，软件的优先级随着时间的经过而提高，因此，软件的优先级最终会高于提取出的全部控制的优先级，由此，软件被更新。

在实施方式1中，在影响度为阈值以上的情况下，假设对楼宇机器30施加的负荷最终会降低，由此，影响度最终会低于阈值，因此，等待到该时刻进行软件的更新。在本实施方式中不需要这种假设。即，如果楼宇机器30的负荷持续一定以上处于较高的状态，则无法更新软件。因此，为了能够应对这种情况，对软件和控制设定优先级，在无法进行软件的更新的状态持续的情况下，根据与也许将会重复执行的控制之间的优先级的关系，在软件的更新处理的优先级高于执行控制的优先级时，进行软件的更新。由此，虽然也许会对控制的执行造成些许影响，但是，能够避免不执行软件的更新的状态持续。

实施方式3

图12是本实施方式中的楼宇机器的结构框图。对与实施方式1(图1)相同的结构要素标注相同标号并省略说明。另外，楼宇机器30的硬件结构可以与实施方式1相同。

在本实施方式中，具有在实施方式1所示的结构中追加负荷模型存储部39而成的结构。负荷模型存储部39中存储的负荷模型是定义了对楼宇机器30施加的负荷的时序变化的模型数据，是根据过去的负荷转变而生成的。例如，在执行负荷较高的控制或者同时执行多个控制时，对楼宇机器30施加的负荷提高。此外，在负荷模型中，不仅是负荷的转变，还可以与时间相关联地设定控制中的时段、或者维护中或累计中(例如日报处理的控制程序动作时)等表示楼宇机器30的利用状况的信息。可以从远程监视中心1取得楼宇机器30的当前的利用状况。

接着，使用图13所示的流程图对本实施方式中的软件更新处理进行说明。另外，对与实施方式1相同的处理步骤标注相同的步骤编号并适当省略说明。

另一方面，在影响度为阈值以上的情况下(步骤106：是)，本实施方式中的更新判定部33从负荷模型存储部39取得负荷模型，根据负荷模型识别当前时点以后的负荷水平的动向(步骤301)。这里，在判断为对楼宇机器30施加的负荷今后上升的情况下(步骤302：是)，对软件更新部34进行指示，由此更新软件(步骤107)。

另一方面，在判断为对楼宇机器30施加的负荷今后不上升的情况下(步骤302：否)，不进行软件的更新指示而返回步骤104。

在实施方式1中，在影响度为阈值以上的情况下，假设对楼宇机器30施加的负荷最终会降低，反复进行步骤104～106。但是，还考虑对楼宇机器30施加的负荷降低但此后反而上升的情况。

因此，在本实施方式中，参照根据过去的实绩而生成的负荷模型，在当前时点以后负荷不会降低即不能预估影响度低于阈值的情况下，即使影响度为阈值以上，也强行进行软件的更新。这样，能够避免不执行软件的更新的状态持续。

另外，在上述说明中，仅关注于负荷的转变来判定可否进行软件的更新。但是，在附加有控制中等表示利用状况的信息的情况下，也可以还参照该信息来判定可否进行软件的更新。例如，即使今后存在负荷上升的倾向，如果最近存在不执行任何控制的维护中的时段，则使软件的更新等待到该时间为止。或者，即使今后存在负荷降低的倾向，如果当前时点以后不久持续处于控制中，则在处于维护中的当前时点执行软件的更新。这样，可以在负荷的转变的基础上，参照过去的楼宇机器30的利用状况判定可否进行软件的更新。

另外，在本实施方式中，为了简便，对具有1个负荷模型的情况进行了说明，但是，也可以根据营业日/休息日、时节等准备多个负荷模型。

此外，本实施方式作为在实施方式1中追加的功能进行了说明，但是，也可以与实施方式2组合实施。

但是，除了所述实施方式以外，也可以如下变形实施。例如，状态监视部32监视对楼宇机器30施加的负荷的状态，但是，也可以在此基础上，将特定软件，具体而言为作为更新对象的软件或与该软件协作执行的软件、或优先级较高的控制软件等的动作状态作为监视对象。而且，在特定软件动作中的情况下等待进行软件的更新。

此外，在上述各实施方式中，在步骤106中与影响度进行比较的阈值是固定值。但是，也可以如负荷模型那样根据时间来改变设定值。

此外，在上述各实施方式中，在楼宇机器30中进行该楼宇机器30的软件的更新控制，但是，也可以通过其他装置例如网关这样的其他装置进行楼宇机器30的软件的更新控制。在顾客楼宇3中设置有多个楼宇机器30的情况下，也可以通过管理多个楼宇机器30的楼宇管理装置进行软件的更新控制。或者，也可以从远程监视中心1进行软件的更新控制。

此外，在顾客楼宇3中设置有多个楼宇机器30的情况下，在多个楼宇机器30协作进行动作的情况下，也可以还考虑其他楼宇机器30的负荷，即还参照其他楼宇机器30的状态信息来计算影响度。在远程监视中心1进行软件的更新控制的情况下，也可以考虑其他顾客楼宇3的楼宇机器30的负荷。该情况下，远程监视中心1进行顾客楼宇3中的软件的更新管理，但是，该情况下，也可以根据计算出的影响度决定软件更新的顺序。

进而，在本实施方式中，在楼宇机器30中自动判断可否进行楼宇机器30中的软件的更新，但是，也可以在楼宇机器30中设置通知部，询问顾客可否进行软件的更新。

标号说明

1：远程监视中心；2：顾客事务所；3：顾客楼宇；4：顾客用网络；5：机器用网络；11：管理终端；12：软件管理服务器；13：顾客信息管理服务器；14：顾客服务服务器；15：楼宇机器管理装置；16：内部网；20：顾客终端；30：楼宇机器；31：更新请求受理部；32：状态监视部；33：更新判定部；34：软件更新部；35：控制部；36：软件存储部；37：更新请求信息存储部；38：控制调度信息存储部；39：负荷模型存储部；41：CPU；42：ROM；43：RAM；44：硬盘驱动器(HDD)；45：网络接口(IF)；46：内部总线；331：影响度计算部；332：优先级设定部。

Claims

1.一种软件更新管理系统，其特征在于，该软件更新管理系统具有：

控制调度信息存储单元，其存储定义了机器设备的控制调度的控制调度信息；

受理单元，其受理包含有在所述机器设备中进行动作的软件的更新预定时间和更新所要时间的更新请求信息；

状态信息取得单元，其取得表示对所述机器设备施加的负荷的状态的状态信息；

更新判定单元，其判定可否进行软件的更新；以及

更新单元，其根据来自所述更新判定单元的指示进行软件的更新，

所述更新判定单元包含影响度计算部，该影响度计算部参照所述状态信息，计算表示影响的程度的影响度，达到更新预定时间的软件的更新处理不仅对所述控制调度信息中定义了调度的控制造成所述影响，而且对所述控制调度信息中未定义调度的控制也造成所述影响，

在计算出的影响度为规定的阈值以上的情况下，所述更新判定单元不指示所述更新单元进行该软件的更新。

2.根据权利要求1所述的软件更新管理系统，其特征在于，

在所述控制调度信息中预先设定有针对所述机器设备的各控制的优先级，

所述更新判定单元包含优先级设定部，该优先级设定部针对成为更新预定时间也未被执行更新的软件，设定与从更新预定时间起的经过时间对应的优先级，

即使该软件的影响度为阈值以上，在该软件的优先级高于在要执行该软件的更新时反复执行的控制的优先级的情况下，所述更新判定单元也指示所述更新单元进行该软件的更新。

3.根据权利要求1所述的软件更新管理系统，其特征在于，

所述软件更新管理系统具有负荷模型存储单元，该负荷模型存储单元存储定义了对所述机器设备施加的负荷的时序变化的负荷模型，

即使该软件的影响度为阈值以上，在通过参照所述负荷模型而判断为对所述机器设备施加的负荷今后上升的情况下，所述更新判定单元也指示所述更新单元进行该软件的更新。

4.一种软件更新方法，其特征在于，该软件更新方法包含如下步骤：

受理包含有在机器设备中进行动作的软件的更新预定时间和更新所要时间的更新请求信息；

从控制调度信息存储单元读出定义了机器设备的控制调度的控制调度信息；

取得表示对所述机器设备施加的负荷的状态的状态信息；

参照所述状态信息，计算达到更新预定时间的软件的更新处理不仅对所述控制调度信息中定义了调度的控制而且对所述控制调度信息中未定义调度的控制造成的影响度，

在计算出的影响度低于规定的阈值的情况下，进行该软件的更新。