基于本体的BAS控制逻辑建模

基于本体的楼宇自动化系统控制逻辑建模

摘要

在楼宇自动化系统（BAS）中实现的控制逻辑对建筑的整体能源需求具有显著影响。然而，有关控制逻辑的信息（如果已记录）通常被隐藏在使用不同数据格式的异构信息孤岛中，难以进行进一步的数据集成和重用。特别是，现有数据格式和信息模型在显式描述控制逻辑方面支持有限。基于本体的建模方法有望为楼宇自动化系统中的控制逻辑提供一种多功能的信息源，从而推动信息驱动过程，进一步提升建筑内技术设备的性能。因此，我们提出了一种新颖的信息模型CTRLont，可用于正式规范楼宇自动化系统中控制逻辑的领域。我们通过将该信息模型用作知识库，以实现对楼宇自动化系统中设计的控制逻辑进行自动化基于规则的验证，展示了其有效性。我们成功地将该方法论应用于空气处理机组的简单控制案例，并指出了若干未来的研究方向。

索引词 —本体，控制，状态机，状态图，时间表，楼宇自动化系统

I. 引言

AUTOMATION 系统是实现商品和货物大规模生产以及技术系统（例如建筑）自动化以实现资源高效运行的关键组成部分[1]。在建筑领域，楼宇自动化系统（BAS）被认为是提高现有和未来建筑物能效的关键技术[2],[3]。相关标准（例如EN 15232[4], LEED [5]）规定了BAS的使用。此外，在办公建筑中，通过部署配置合理的BAS，最多可实现30%的供暖节能[4]。文献[3]提供了与建筑相关的能源和舒适度管理控制系统的综述。然而，BAS的实际应用往往未能达到预期的能效目标。这类故障的楼宇自动化系统导致了建筑预测与实际能源需求之间的差距[6]。为了有效设计、调试和运行高能效的楼宇自动化系统，迫切需要交换其最核心部分——控制逻辑的相关信息。

楼宇自动化系统生命周期内的信息交换，包括其控制逻辑，通常由文本描述、电子表格和二维图纸组成。此类交换相关标准建议在楼宇自动化系统（BAS）领域将[7]–[9]用于设计文档以及调试后的信息移交。因此，根据这些非结构化文档验证控制逻辑的正确运行[10],[11]，或检查楼宇自动化系统是否符合能效等级[4]，都是繁琐、耗时且成本高昂的任务。此类过程需要对设计阶段的控制逻辑进行结构化定义，明确楼宇自动化系统中所有控制执行器的逻辑拓扑关系的绑定，提供控制实体与建筑构件和设备之间归属关系的上下文信息，以及有关输入和输出（例如测量量）的附加信息。综上所述，现有楼宇自动化系统中控制逻辑信息交换存在的问题包括： 1）依赖文本描述、电子表格和图纸；2）相关信息具有异构和分布式特性，分布在各种格式和信息孤岛中，且未定义通用语义；3）缺乏统一的方式从相邻信息领域（如建筑构件和设备）提供上下文信息。

为了解决上述问题，已有若干研究致力于对与楼宇自动化系统相关的信息进行建模，如第二节所述。然而，这些研究均未满足适当的信息模型所需的所有要求，以克服所总结的问题： 1) 控制执行器及其相关语义的高层描述，即输入、输出、参数、控制执行器及其逻辑，以及它们之间的领域特定关系，例如层级和逻辑绑定；2) 控制逻辑本身的形式化规范；3) 输入和输出的上下文信息：单位、介质、量纲、与建筑构件和设备的归属关系；4) 模块化结构，以确保便于扩展未来的新型控制逻辑，并鼓励在相邻信息领域中重用现有本体；5) 使用机器可解释格式，以支持基于该信息的智能自动化应用。

本文的贡献在于提出了一种新的信息模型，称为 CTRLont，旨在满足上述五个需求，从而能够以正式且统一的方式将控制逻辑的显式模型与相邻的信息领域进行集成。CTRLont 可用于规定控制执行器的输入和输出，例如单位、物理量等。此外，还可以对控制领域中的控制执行器及其相关语义进行描述。

抽象层次。CTRLont支持以模块化方式集成控制逻辑的显式描述，从而实现易于重用和扩展。该模型使用网络本体语言（OWL）[12],实现，使其可通过语义搜索和推理在智能应用中重用。此外，我们提供了信息模型，用于显式建模定义为UML状态机[13],状态图[14]和时间表的控制逻辑。

在后续章节中，我们首先分析楼宇自动化系统中控制逻辑信息建模的相关工作（第二节），以评估其满足所定义需求的能力。然后介绍新型信息模型（CTRLont，第三节）以及控制逻辑的显式规范（第四节）。最后，通过在一个用例中实现对设计的控制逻辑进行自动化基于规则的验证，展示该新型模型的有效性（第V节）。

二. 相关工作

A. 控制逻辑表示的通用格式

控制逻辑通常使用UML状态机[13]进行设计。UML是一种在各个领域广泛接受且标准化的建模语言。可用于在UML编辑器之间表示和交换这些设计的一种格式是基于XML的数据格式XML元数据交换（XMI）[15]。然而，由于UML旨在描述通用应用，因此无法以统一的方式表达与楼宇自动化系统相关的某些特定信息。例如，技术设备的归属关系或输入变量的详细语义在UML中并未统一定义。

工业自动化系统中的另一种格式在 IEC 62714[16] 中进行了标准化。在此标准中，控制逻辑通过开放的 PLCopenXML [17] 格式进行交换。该格式允许将逻辑拓扑指定为有向图，并定义接口变量的基本数据类型，例如整数。实际的控制逻辑通过包含 IEC 61131‐3[18] 中五种语言之一实现的源代码来指定。PLCopenXML 数据格式涵盖了控制执行器的高级接口描述，例如逻辑拓扑。然而，当需要详细说明输入或输出的单位或量纲时，存在局限性。此外，由于该格式仅存储纯文本源代码，因此在使用基于文本的 IEC 61131‐3[18], 编程语言时，控制逻辑的形式化规范受到限制。

一种源自异构计算模型建模的努力催生了建模标记语言（MoML）[19],，该语言基于XML实现，并支持系统的基于角色的描述。MoML [19]的基于角色的基础能够实现对控制执行器及其相互关系的高层描述，例如输入连接到输出。然而，该建模语言缺乏表达控制执行器与建筑构件和设备之间归属关系的能力。

最后，使用EXPRESS数据建模语言实现的楼宇自动化系统信息模型[20]涵盖了控制执行器（层级、逻辑拓扑）的高层描述及其与相邻领域信息的集成（网络、数据点、建筑构件和设备）[21]。然而，该方法在指定例如输出的单位等细节时依赖于命名约定。这为互操作性和重用带来了严重障碍。

B. 使用网络本体语言（OWL）表示控制逻辑

文献中的多个示例使用OWL（网络本体语言）[12]来表示楼宇自动化系统，旨在对楼宇自动化系统的描述进行正式化，并实现与相关信息领域的关联。这两个主要目标正是语义网理念的核心。关于语义网技术的全面介绍可参见[22],，而建筑领域中该主题的概述则在[23]中提供。

例如，DogOnt [24] 是一个用于描述住宅环境（如互联家电）的本体。对于更广泛的用例，ThinkHome本体对住宅建筑中能源分析所需的所有相关信息进行了正式化，包括环境气象条件、建筑结构与材料、家电、舒适度、能源、过程和时间表[25]。智能家电参考本体（ SAREF）是领域专家就智能家居家电达成的共识，该共识是在审查了该领域现有本体后建立的[26]。

一些方法侧重于能源管理方面的信息集成。[27]提出了一个机场设施的本体，该本体根据ISO 50001[28]构成一个能源管理的知识库。[29],也提出了一种类似的方法，但更侧重于能源系统建模。[30]提出了一项利用本体进行建筑物能源性能评估的跨领域数据集成的显著研究成果（“性能评估本体”）。关于为楼宇自动化系统定义领域本体（BASont）的重要工作记录在[31]–[33]中。该研究旨在应对楼宇自动化系统中由于广泛使用的数据格式和通信协议所导致的异构性和互操作性问题。部分已开发的本体被用于自动化楼宇自动化系统的设计过程[33]。

通过信息模型捕获更广泛领域的信息，这些模型旨在涵盖与建筑相关的所有信息，以实现其生命周期内的无缝信息交换（建筑信息模型（BIM））。此类模型包括建筑构件和设备、几何信息、楼宇自动化系统（BAS）以及过程和项目管理的信息[34]。行业基础类（IFC）是由 buildingSMART开发的一种信息模型，用于描述上述信息。它采用EXPRESS数据建模语言实现[20] ，并已被转换为XSD和OWL[35]。与IFC密切相关但应用于能源仿真领域的是SimModel [36]，其目标是弥合建筑信息模型（BIM）与建筑能耗性能仿真之间的差距。SEAS本体是一组面向工程领域的高层本体，为楼宇自动化系统（ BAS）中的数据点提供了抽象层面的概念[37]。

C. 概要

在审查了现有的数据格式和本体后，未发现任何一种能够满足引言中规定的全部五项要求。在OWL以外的语言中定义正式语义是可能的，但由于其依赖于XML或EXPRESS技术（如第二节‐A所述），这种能力受到限制。与楼宇自动化系统（BAS）相关的基于本体的建模方法中的现有概念化方案（如第二节‐B所述）均针对各自的应用领域进行了定制，即智能家居与家电、能效、建筑信息模型（BIM）以及楼宇自动化系统（BAS）。所有模型均使用OWL实现，从而支持将这些本体所建模的信息用于智能应用的重用。这些本体包含了用于描述建筑构件和设备的概念，以及楼宇自动化系统中的物理实体（如设备、传感器、执行器）和虚拟实体（例如数据点、控制执行器等），其描述程度和分辨率各不相同。然而，现有报道的方法均无法对楼宇自动化系统中存在的控制逻辑进行显式建模。相反，这些方法试图通过广泛的分类方案来捕捉控制逻辑，其中一个概念代表一种类型的控制逻辑[24]–[27],[36]，或引用标准中提供的定义[33]。为了弥补楼宇自动化系统中控制逻辑显式建模方面的现有空白，本文提出了一种新颖的信息模型，将在本文余下部分进行介绍。

III. CTRLONT 本体

在本节中，我们将描述用于形式化楼宇自动化系统中控制逻辑的所建模本体的架构。该建模采用OWL进行， OWL作为一种具有描述逻辑坚实基础的表达性强的正式语言，具有诸多优势。此外，使用OWL有助于实现集成新型模型与现有领域模型（第二节‐B）的对比，并通过语义搜索和推理推断出新的见解。在设计CTRLont本体时，我们遵循了结构化的方法[38]，并参考了第二节中记录的现有概念化成果。所有本体均使用图结构表示，如图1所示。本文所采用的命名规范和命名空间如图2所示。为了提高可读性，我们在本体可视化中省略了施加的限制条件（如基数限制、全称限定、存在限定、类型限制）。

CTRLont 本体（图1）的核心是感知‐处理‐执行模式的定义，这种模式在控制领域中被广泛认可，例如功能配置文件 [7],[8], 功能块 [39] 或通用的面向执行器的建模 [40]。一个ControlActor通常通过Input获取信息，利用某种ApplicationLogic处理这些信息，并通过某个Output[1]执行有依据的执行操作。每个ControlActor实体都通过关系hasApplicationLogic与一个ApplicationLogic实体相关联。对象属性logic-输入、逻辑输出和逻辑参数被定义用于显式建模应用逻辑与输入、输出和参数之间的关系。参数概念描述了相应控制执行器的时间不变值和设置，可根据特定应用逻辑的具体需求进行添加。

在任何楼宇自动化解决方案中，控制执行器实体通过各自的输入和输出相互连接，形成系统的逻辑拓扑。此外，位于现场层/自动化层的实体与位于管理层的实体之间存在层次关系[7]。管理层实体通常监管自动化层和现场层的实体，而现场层实体被管理层实体监管。该隐式层级需要在模型中得以体现，例如用于推断在管理层实施的控制策略是本地控制故障的根本原因。

控制执行器（ControlActor）的概念可用于指定开环和闭环控制实体[41]。对于闭环控制实体，需要在相应的ApplicationLogic中引入特定概念和关系，以将设定值描述为输入或参数。对输入、输出和参数进行进一步注释，对于实现控制执行器实体在软件和自动化系统之间的互操作性和交换，以及楼宇自动化系统（BAS）的自动设计[33]至关重要。特别是需要明确其单位、量纲、介质和语义类型（图1）。我们在此不定义全新的本体，而是为上述概念实现占位符，并建议重用现有本体，例如测量单位本体(OM)[42]。为了能够描述更详细的差异，例如干球和湿球空气温度[33]，可以引入领域相关的语义类型。

概念输入、输出和控制执行器与技术设备（例如空气处理机组控制器）或建筑构件（如空间温度控制）相关。我们建议不通过使用分类法来表达这种关系，而是将这些概念直接关联到相邻领域现有信息模型中的相应概念，例如楼宇自动化系统[32], 、建筑信息模型[35]和技术系统 [37]。

IV. 控制逻辑的显式建模

在本节中，我们提供了一些可用于显式表示楼宇自动化系统中控制逻辑的本体示例，即UML状态机[13],根据 VDI3814定义的状态图6[14],以及状态机和状态图条件中明显的布尔表达式和时间表。所选示例反映了在楼宇自动化系统中频繁部署的控制逻辑的一部分，但并不意味着详尽无遗。这些示例表示图1的下部（Control Logic），从而扩展了上述指定的CTRLONT 本体。

A. UML状态机

UML状态机为建模控制逻辑[13]提供了一种通用方法。我们通过修改一个现有本体，开发了图3所示的本体[43]。我们的修改包括与最新版本的UML标准[13]保持一致，并扩展了守卫以显式包含布尔表达式。从图3可以看出，状态机（ StateMachine）包含状态机元素（StateMachineElement）， 例如状态（State）和转换（Transition）。状态可进一步细化， 例如通过复合状态（Composite）实现。状态之间的转换由事件（Event）触发，并由第IV‐C节中所述本体描述的守卫中的布尔表达式（BooleanExpression）进行约束。状态和转换通常关联有动作（Action）。根据UML标准，动作可以指定任意的行为（Behaviour）。在动作中，输入被转换为输出。在此模型中，我们因此定义了一个占位符概念“行为”（Behaviour）， 其与输入（Input）、输出（Output）和参数（Parameter） 具有关系。第V节末尾简要讨论了指定行为的合适方法。最后， 状态机（StateMachine）概念由状态机元素（ StateMachineElement）特化而来，旨在符合UML对嵌套状态机的定义，即一个状态机可以包含其他状态机。

B. 状态图

根据VDI 3814‐6标准[14]定义了状态图，旨在通过在楼宇自动化系统中表示“特定逻辑联锁”来填补标准化控制描述中的空白。它们用于提供控制逻辑的图形化表示， 以补充文本描述。我们设计了一个如图4所示的状态图本体，同时考虑了先前定义的本体（见图3）。状态图与状态机之间的一个区别在于，在状态图的情况下，触发从一个状态到另一个状态转换的条件仅与状态相关。

设计的本体通过将概念“动作”和“条件”直接与“状态”关联来反映这一细节。根据标准定义，当某个状态及其关联动作为活动状态时，会立即为输出赋值（ assignValue）。一个输出可与状态相关联，以表示指示状态活动的虚拟数据点。该标准还定义了与状态图分开的功能块，可用于转换所分配的值，可能涉及将输入转换为输出。由于此功能块构成独立的应用逻辑，因此此处不作具体说明。

如果有多个转换指向同一个状态，则需要使用 transitionCondition 对象属性将条件与相应的转换关联起来。输入和条件的实例之间的关系如第IV‐C节所述。

C. 捕获条件逻辑

条件逻辑的描述是连接基于状态的控制逻辑（如 UML状态机与状态图）中的概念与控制执行器输入的核心要素。例如，在UML状态机中，从一个状态到另一个状态的转换可能受到守卫的限制，该守卫指定了一个条件 y<= 1。在XMI或MoML等数据格式中，此信息以纯字符串形式存储，忽略了该信息的实际语义（第二节）。而图5所示的本体则能够对基于状态的控制逻辑转换中出现的条件进行形式化表达。我们假设这些条件逻辑片段表示为布尔表达式，可通过逻辑合取（AND）、逻辑析取（OR）和逻辑否定（NOT）进行连接和嵌套。布尔表达式的主体通常包含表达式的左侧和右侧。左侧与右侧之间存在某种关系，用于描述两者之间的比较方式，例如等于。该表达式与输入的归属或参数可以分别使用logicInput和logicParameter属性来表示。

D. 时间表

时间表是楼宇自动化系统中常见的控制逻辑。通过将设备运行与占用时段对齐，时间表提供了一种简单直接的方式来降低建筑的能源需求。图6展示了一个用于以通用方式描述时间表的本体。

时间表被建模为一组连续区间，这些区间由其开始和结束点定义，并通过一个描述其间关系的数学函数来表示。我们假设仅出现多项式函数。明确建立了与相应时间表的输入和输出之间的关系。此外，周期性概念可用于指定时间表是每日、每周还是每年重复。

V. 用例

在下一节中，我们将通过自动化实现[10],[11]提出的楼宇自动化系统中设计的控制逻辑的基于规则的验证方法，强调基于本体的控制逻辑显式建模的有用性。

A. 楼宇自动化系统中设计的控制逻辑的自动化基于规则的验证

对于控制逻辑设计人员来说，在调试完成后几乎无法验证设计阶段的控制逻辑是否按照规范实施。这主要是由于以下原因：跨季节和运行模式的数据监控尚不可用，且通常实现的源代码是隐蔽的。[10] 提出了一种解决此问题的方法论。该方法依赖于领域专家对楼宇自动化解决方案的现有文档进行分析，并据此定义验证规则以评估监控数据。显然，手动分析这些文档非常耗时，因为文档分散在各种数据格式中，包括文本描述、电子表格和图纸。为了避免这种劳动密集型的任务，我们建议采用如图7所示的自动化流程。

首先，从楼宇自动化系统的先进设计工具中提取并形式化描述控制逻辑设计及相应数据点的数据。结果存储在知识库中。基于专家知识得出的用于验证特定控制逻辑类型的原型规则被编码为参数化查询。接下来，通过向知识库发送固定查询来检索配置这些编码了原型规则的参数化查询实例所需的信息。通过部署配置的查询来评估监控数据。在此方法中，某一时间点上与设计的控制逻辑的偏差被解释为故障征兆。结果被存储并可视化，用于故障隔离和后处理，例如通过计算加权运行质量[10]。

B. 实施与结果

上述方法已使用Python编程语言实现，并在一个虚构的空气处理机组（AHU）测试案例中进行了部署。首先，我们描述该测试案例的设置；然后展示填充上述本体和查询的实例，以按照图7所示流程实施该方法。最后，我们展示了将该方法应用于模拟数据所得到的结果。

所设计的相对简单的控制由两个控制执行器、一个时间表和一个状态图组成。控制逻辑的拓扑结构、其与输入和输出的连接关系以及控制逻辑的图纸在图8中进行了说明。该时间表将空气处理机组风扇和泵的运行时间限制在上午8点至下午6点之间的占用时段。通过状态图对空气处理机组的实际运行进行建模，使其处于“关闭”、“启动”和“开启”三种状态。图中以圆圈表示的返回状态作为占位符，当相关联的布尔表达式为真时，会跳转到相应的状态。为了防止加热盘管因冻结而受损（当室外空气温度 Toa低于1摄氏度时），控制逻辑仅在启动阶段通过循环回风YMix:= 0来运行空气处理机组。当加热盘管水路回水温度Thcr达到30摄氏度时，开始正常运行（开启），此时混合箱风门YMix保持固定开度。

图9展示了图8中所示设计的控制逻辑的实例片段，这些实例存储在知识库中。注意，这里我们使用SEAS本体在抽象层次[37]上对楼宇自动化系统的数据点进行建模。该信息被检索用于配置实现原型规则的参数化查询。例如，代码1中的 SPARQL查询可用于配置所列出的参数化查询的实例在代码2中（也通过SPARQL [44]实现）。代码1中查询在状态关闭下的结果列于表I。可根据专家知识定义以下原型规则：如果某个状态为活动状态，则应执行其关联动作[10]。因此，可以查询监控数据，查找实际值与从设计规范获得的相应值不同的情况。对于所展示的用例，实现此功能的参数化查询由代码2给出。类似地，也可针对时间表制定原型规则和查询。

代码1：用于检索配置代码2中列出的参数化查询所需信息的查询。

前缀 [...]
选择 ?vState ?vDPState ?vDPMeas ?vValue 其中 {
  ?vSG rdf:type SG:状态图 ; SG:包含 ?vState .
  ?vState rdf:type SG:状态 .
  ?vState SG:状态动作 ?vAction .
  ?vAction rdf:type SG:动作 .
  ?vAction SG:assignValue ?vValue .
  ?vAction ctrl:logicOutput ?vOutput .
  ?vOutput rdf:type ctrl:Output .
  ?vOutput seas:connectsSystemThrough ?vConn .
  ?vDPMeas seas:connectsSystemThrough ?vConn .
  ?vDPMeas rdf:type seas:Communication 连接点 .
  ?vState ctrl:logicOutput ?vOutputS .
  ?vOutputS rdf:type ctrl:Output .
  ?vOutputS seas:connectsSystemThrough ?vConnS .
  ?vDPState seas:connectsSystemThrough ?vConnS .
  ?vDPState rdf:type seas:Communication 连接点 .
}

表I：从知识库中检索到的关于stateOff的示例信息。
| vState | vDPState | vDPMeas | vValue |
|------------|----------|---------|--------|
| :StateOff | :id5 | :YMix | ’0’ |
| :StateOff | :id5 | :YFan | ’0’ |
| :StateOff | :id5 | :YPump | ’0’ |

代码2：用于过滤具有错误状态图行为的时间点的参数化 SPARQL查询。

前缀 [...]
选择 ?主键 ?时间值 其中 {
  ?主键 a tb:主键 .
  ?主键 tb:时间 ?时间值 .
  ?主键 tb:$vDPMeas$ ?y输出值 .
  ?主键 tb:$vDPState$ ?y状态值 .
  过滤( ?y状态值="1.0" && ?y输出值 != "$v值$" )
}
按顺序排列 ?时间值

此处，我们选择使用一种简单的转换方法，将仿真获得的监控数据以RDF格式[46]存储，该方法将每次采样测量建模为主键个体。读数通过OWL对象属性（例如 tb:YPump）与这些个体关联，该属性以其读数的唯一标识符作为URI。本例中我们使用了一个任意前缀(tb:)。由$包围的字符串是占位符，并在查询的配置实例中被替换。为了部署所有已配置的查询并遵循[10],所提出的运行状态空间（OSS）概念，所有查询实例通过UNION连接嵌套到一个查询中（代码3）。子查询嵌套确保了 SPARQL端点高效执行该查询。然后，该查询在监控数据上执行，以过滤具有症状行为的时间点。

代码3：用于评估监控数据的组合查询。

在下文的讨论中，我们从上到下依次列举图10中的子图。假设状态关闭为活动状态（1），泵的归一化控制信号YPump应为零（2）。然而，在故障数据中，该信号保持在1.0（3）。时间点通过代码2中给出的查询的独立实例或代码3中聚合的所有实例进行过滤（4），然后由系统解释并报告。

指示关闭状态是否激活的信号；(2) 用于比较的正确设计行为；(3) 带有故障控制信号的YPump的整体行为评估结果；(4) 运行代码2中查询实例（YPump!= 0）以及代码3中报告的组合查询（OSS）所得结果的解释；如果查询返回一个或多个个体，则相应的时间点被解释为有症状的（真），否则为无症状的（假）。YSce、YMix、YFan、YPum p ——来自时间表、混合箱风门、风扇和泵的归一化输出信号，OSS ——操作状态空间评估结果。)

C. 讨论

在所述领域中应用基于本体的建模方法可识别出多个优势。该通用建模方法能够定义和表达不同信息域之间的关系，包括建筑构件与设备、控制逻辑的显式模型、楼宇自动化系统的静态信息以及监控数据。此外，该方法允许以更详细和结构化的方式对控制逻辑进行建模。例如，现在可以显式地建模状态机和状态图中出现的布尔条件，并定义其语义。目前可以在建筑房间内安装的物理传感器、其关联的虚拟数据点以及评估该值的控制逻辑之间建立关系。此领域的信息随后可用于智能应用，如第V‐A节中所述的自动化基于规则的验证。

所提出的用例能够检测由控制逻辑故障引起的故障。然而，为了找到合适的补救措施，需要确定其根本原因（故障隔离）。[48]。支持这一点的有前景的工作已在[49]中提出。本工作中提出的本体可以扩展所述方法的解释空间，例如通过反向故障传播来识别故障的根本原因。此外，还可以通过正向故障传播评估控制逻辑故障对相关建筑元素和设备的影响，其中控制逻辑的异常行为是通过本文提出的方法识别的。当然，定义因果关系和故障传播关系需要专家知识。

在对UML状态机进行建模时，输入与输出之间的实际关系由动作处于活动状态时执行的相应行为建立。如前所述，这种行为可以接近任意形式。这种自由度给建模方法带来了限制。需要进一步研究以找到合适的行为描述方式，这些方式可能从通过OpenMath [50]编码的数学表达式到UML活动图[51]不等。

六、结论

本文提出了一种新颖的信息模型CTRLont，该模型为在楼宇自动化系统中形式化控制逻辑信息奠定了基础。所定义的概念与关系支持将控制逻辑的显式规范以及相邻信息领域（即楼宇自动化系统、建筑信息模型和建筑管理系统（ BMS））进行集成。我们提出了用于正式规范基于状态的控制逻辑的模型，包括UML状态机与状态图，以及时间表。

我们通过将新模型用作知识库，以实现对设计的控制逻辑进行自动化基于规则的验证，从而展示了其有效性。其中，规则被动态配置，并应用于从虚拟BMS实例中获取的监控数据。我们已成功将该方法论应用于空气处理机组控制测试案例。采用此方法论，可以减少在阅读楼宇自动化系统中控制逻辑文本描述上所花费的时间，使工程师和设施管理者能够投入更多时间来识别故障的根本原因。

我们假设，设计的本体可以从控制逻辑设计人员所使用的创作工具中自动填充（通过导出器/适配器）。

所提出的本体可作为自动化领域中建立控制逻辑共同理解的催化剂。它能够推动未来新型智能方法的发展，以改善建筑运行，例如在楼宇自动化系统中定制基于规则的控制逻辑验证，或扩展基于知识的方法的解释空间，用于检测建筑物中故障的根本原因[49]。例如，通过正向故障传播估计控制逻辑故障的影响，或通过反向故障传播将控制逻辑故障识别为（一个）根本原因。

关于所提出的基于本体的控制逻辑建模，仍然存在一些挑战： 已部署控制逻辑的复杂性：一般来说，楼宇自动化系统中的控制逻辑可能从简单的PID控制器到应用于建筑中各种过程的高级预测性和自适应控制器不等。[3]。这种复杂性对在本体方面就此类先进控制器达成共识的程度构成了障碍。

•知识产权： 在上述报告的自动化方法中，规则的执行需要将基于状态的控制器中当前活动状态的信息作为输入。在这些控制器的实际实现中，由于提供设备的公司出于知识产权（IP）原因，此类信息通常被隐藏。这与复杂性相关，因为控制逻辑越先进，知识产权方面的顾虑通常也越多。需要开发合适的替代方法来自动识别运行状态，例如通过评估空气处理机组送风管道中测得的压差来确定其运行状态，如[10]所建议的。

这些挑战中的大多数也存在于非本体方法中。此外，还可以提出一些未来的研究方向：

本体链接： 所提出的本体的现有实现是从头开始进行的，以确保可用性和语义正确性。然而，为了最大限度地利用语义网技术，需要规定与领域内现有本体的集成，例如BASont[32], ifcOWL [35], seas [37], OM [42], OpenMath [50]和 SSN[52]。

•楼宇自动化系统中的基于模型的信息交换：当前用于设计楼宇自动化解决方案的工具以各种格式存储设计信息。需要付出努力以实现楼宇自动化系统生命周期内的标准化基于模型的信息交换。

对现有控制逻辑文档进行形式化： 需要找到新的方法来对来自现有文档的控制逻辑数据进行形式化。一种途径是扩展和优化现有数据格式，例如PLCopenXML [17]。[53]开展的建模工作可能是一个良好的起点。另一种途径可能是针对基于电子表格和图纸的当前文档，通过使用半自动流程提取其中的信息[54]。