英语原文共 9 页，剩余内容已隐藏，支付完成后下载完整资料
楼宇自动化系统的自动化设计
Henrik Dibowski，JoernPloennigs，IEEE会员，Klaus Kabitzsch，IEEE会员
摘要——具有数以千计个设备的大型楼宇自动化系统（BAS）的设计是一项十分艰巨的任务，这需要对相同的自动化房间进行大量的重复性工作。如今虽通过提前制作设备和设计模式简化了这项任务，但也带来了新的互操作性问题。因此，设备的选择对于良好的系统设计是必不可少的，但通常由于缺乏信息而受到限制。本文介绍了一种新颖的大型BAS自动设计方法，该方法涵盖了设备选择，互操作性评估和BAS的组成。它具有不同抽象层次的连续的自上而下的设计，从需求工程开始，一直到功能完善的跨行业BAS设计结束。
- 导言
高效的设计方法是自动化网络进一步发展的重要前提。如今，不仅要统计网络中设备的数量，还要处理复杂的设备交互问题。如[1]中介绍的新智能控制功能，结合了多个信息源来执行任务。这增加了每个设备的设计复杂性和设备变型的数量，导致难以选择合适的设备，并且互操作性不佳是一个永恒的问题。
为了减少设计工作，业界使用具有预实现配置文件的现成设备。在有关BAS的文章以及本文中，配置文件是具有输入和输出数据点的面向功能块的应用程序，可以与其他配置文件连接以形成逻辑网络，它们可以实现标准化的配置文件，因此不应理解为传统自动化意义上的配置文件，而应理解为制造商特定的标准化配置文件的实现。
专业设计工具已经问世多年了。他们将系统设计简化为设备及其配置文件的选择、参数的设置和数据点连接的定义。每个设备只有几分钟的时间来完成这些任务。然而，如第二节所示，大多数工程任务仍然是手工作业，并承担着若干风险，使该过程不可改进。
本文介绍了一种旨在克服这些问题的新颖的楼宇自动化系统（BAS）自动化设计方法。 它总结了德国研究项目“ AUTEG-楼宇自动化设计”（http://www.ga-entwurf.de）的结果，该项目由大学和公司共同执行。 它是由德国联邦经济技术部根据德国议会的决定资助的（资助编号：16IN0405）。
- 相关工作
- BAS的设计
BAS的工程涵盖了从系统的项目计划到调试的整个过程[2]。 设备的配置是此过程的一部分，包括以下步骤：
1）选择适当的通信技术；
2）将功能需求分解为配置文件；
3）选择实现概要文件和实现新的不受组件支持的设备
4）设计网络拓扑和布线；
5）为设备分配逻辑地址；
6）定义配置文件的数据点之间的通信连接；
7）设置设备参数。
此配置过程的步骤4）到7）通常使用专门的商用软件工具（如LonMaker，Engineering Tool Software，ALEX，NL220或NLFacilities [3]）。这些工具支持离线设计，无需现有网络，并且已经可以执行自动寻址等步骤。当所有设备物理分配了它们的地址，参数值和通讯连接时，调试期间工具会自动将整个设计下载到网络中。配置与调试过程的这种分离旨在减少在建筑物侧花费的时间，并允许事先进行特定的系统设计。但是，这种经典的网络设计具有它的缺陷。92％的系统集成商报告了互操作性和设备选择方面的常规问题。这使得调试和配置一样耗时，并且使反复试验方法的两个步骤都变得复杂[4]。
- 互操作性
当系统集成商在第三步设计中选择设备时，就已经引起了互操作性问题，即两个设备不能正常工作。这意味着系统集成商首先将所需的功能分解为配置文件，然后在他的脑海中创建一个概念设计。设计工具不能用于此步骤，因为不支持设备搜索功能，必须手动选择配置文件和设备。因此，他必须将自己的设计理念与可用的设备文档以及他的经验进行结合，以选择合适的设备并评估它们的互操作性。由于功能和制造商种类繁多，他可以从市场上数千种设备中进行选择。这是一项艰巨的任务，他常常会遇到来自同一制造商却无法都正常工作的设备。
所有具有互操作性标准的广泛的楼宇自动化技术（如KNX，LON和BACnet）都解决了互操作性问题。这些标准涵盖了不同的功能级别，从指定数据点的变量类型（如温度）到定义标准化配置文件[5] – [7]。特别是，较低级别的标准（变量类型和服务）在域中被接受，而标准化的配置文件通常是模糊的。原因是标准化的配置文件通常只考虑所有制造商共享的少数共同属性。每个制造商都增加了特定的扩展名，而这些扩展名的互操作性又没有保证。此外，标准化配置文件缺乏形式上的定义。该规范限于数据点的语法定义和配置文件功能的文本描述。同样不能保证相同的变量类型由不同的配置文件实现。但是，配置文件的动态行为也会影响它们的互操作性，这也不是标准化配置文件的一部分。所以，互操作性标准和标准化配置文件是解决互操作性问题的重要步骤，但却无法彻底解决。
- 设计自动化
解决互操作性问题的其他方法已经朝着自动化设计的方向发展。 Stein [8]提出了一组称为协作性可互操作功能块的标准化设计模式的形式化定义。对于KNX和LON [9]或者是UPnPapproaches [10]，[11]，在通用的即插即用概念中也使用了这种可互操作的设计模式，其中预定义了可连接设备对。 仅使用一个产品线，就简化了封闭系统的设计和调试。 但是，它必定会在多厂商系统中失败，因为它假定互操作性是可标准化的。
加快设计过程的另一种最佳方法是使用设计模式。尽管安装的BAS大多是唯一的，但对于建筑物细分（例如房间，区域和地板）而言却有所不同。这里，存在许多循环设计模式，主要覆盖功能设计级别[12]。大多数设计工具都支持复制和粘贴操作，以轻松地复制设计零件。下一步的开发是模式库，它是NL Facilities工具[3]首次引入的。但是，这些库的缺点被称为库缩放问题[13]。随着时间的流逝，库中设计模式的数量不断增加，因为每个模式都需要在下一个项目中进行一些修改。这导致难以区分具有相同模式的多个变量。
生成式编程是解决该问题的一种方法[14]。它使用生成器，按照通用的构造计划和特定于领域的需求定义，结合基本组件中的特定软件产品。生成式编程也可以用于生成基于功能块的设计和适应性资源高效的设备应用程序，而不是软件产品，如[15]和[16]所示。
图1.自动设计工作流程
针对计算机辅助设计的不同领域开发出了自动化设计方法。最早的应用领域之一是嵌入式系统的电路和硬件设计。在该领域，有几种方法着重于用进化算法进行综合设计来优化最终电路设计[17]。
基于组件的软件工程[18]和Web服务[19]使用更抽象的方法来表达和发现服务的能力。
这些方法都不能直接应用于BAS的设计。BAS既不需要在电路层进行优化，也不需要提供可以自由连接的语义服务。但是，所有这些方法都具有相同的思想。根据元素的功能和行为进行语义描述，它对元素的结构进行优化，可能是电路元素，软件组件，服务或功能块。在此介绍的自动化设计方法中也遵循此概念。
- 自动化设计方法
在AUTEG项目中开发的自动设计方法如图1所示。其主要特征是将第II-A节中介绍的工作流程按功能重新排序为自上而下的方法[20]-[22]。 它从建筑物的一般结构信息开始。对BAS的需求是系统集成商，规划人员或所有者在基于知识的过程中提出的。工程师是在自动化设计工作流程中的关键角色。通过应用专门的算法和设计方法，所有后续的设计都会自动进行，直到发布详细的网络设计为止。
首先，通过生成程序来创建定义BAS每个房间功能示意图的抽象设计。抽象设计故意独立于任何平台或制造商。这样可以在功能级别上验证自动化概念，并可以独立于政府经常进行的招标。
之后，使用进化算法在迭代优化过程中完成向具有特定制造商设备和配置文件的平台的过渡。支持不同的技术平台，例如LON，KNX或BACnet。此过程需要有关自动化设备的语义知识，以便能够选择合适的设备和配置文件及其组成，以实现一致的不可操作的多供应商解决方案。因此，引入了语义设备描述，这些描述由基于知识的组件存储库管理和访问。
自动化设计的结果是完全开发了符合需求的多供应商BAS设计。 它已从当今流行的制造商专用产品线解决方案中分离出来，并进行了优化，以提供与市场上所有现有设备有关的高互操作性以及较小的硬件和安装成本。
在以下各节中说明了自动设计方法的所有步骤以及设备和配置文件的语义规范。
A.建筑结构的提取
为了避免费时的编辑，可以从建筑师提供的现有3-D CAD模型中提取建筑结构。通过房间及其部分，模型定义了要设计的BAS的基本结构。 行业基础分类（IFC）数据模型[23]，[24]被当做提取源，这是一个中立且开放的规范，所有主要CAD工具均支持该规范。从给定的IFC建筑物模型中，提取楼层，房间和立面及其布置，以及其他信息，例如窗户的数量，大小和方向。这影响了一些设计决策，例如百叶窗的数量和尺寸。
B.基于知识的需求工程
根据给定建筑物的结构和相应的属性，下一步将对BAS进行规定。在工具支持的基于上下文的基于知识的过程中，从系统集成商，规划人员或所有者那里获得需求。Web本体语言（OWL）[25]中特定于域的需求本体是该过程的基础。由系统集成商直接给出或通过推理得出的所有要求，都由该本体及其之间的关系的实例正式指定。
图2.建筑结构和模板
本体来自人工智能，并已成为广泛领域中被接受的信息表示方法和使用格式。本体表示以一种形式化，声明式和计算机可理解的方式传达和封装概念及其关系。除了其他现有的本体论语言外，OWL近年来已发展成为最主要的语言之一。
本体还可以使用推理引擎来处理信息。因此，OWL需求本体是通过语义网规则语言（SWRL）中的逻辑规则来完成的[26]。因此，推理系统可以推荐合理的需求，检测和解决给定事实和需求之间的矛盾，并通过推理来获得完整的信息。
为了避免重复定义相同的房间，将需求分组到模板中。模板定义对某种类型的房间的要求，例如，具有三个窗口且朝南的两人办公室，系统集成商只需定义一次模板即可将其分配给所有匹配的房间。
需求在功能需求和非功能需求之间进行了区分，如下所述，功能需求指定了BAS应实现的功能。另一方面，非功能需求指定了与制造商无关的设备硬件准则，例如平台，安装形式，入口保护，支持的传输介质或工作电压。它们满足了在创建详细设计期间自动选择合适的设备的要求，从而限制了所得BAS的变化性。
例如，图2显示了研讨会室的平面图，在本文撰写过程中应将其自动化。根据所有者的描述，系统集成商例如定义了会议室的以下功能要求：根据会议室的大小，所有者要求使用两个照明灯。对于第一盏灯，他想根据房间的占用状态，自动激活灯光控制。占用状态由占用传感器和占用开关检测。第二盏灯，他为保持恒定的光水平指定了光控制。此外，灯光还应该可以通过开关手动操作，也可以通过场景面板手动操作。作为非功能性要求，系统集成商指定系统应实现LON网络，其中每个设备都应具有以下属性：防护等级为20或更高，工作电压为24 V dc，传输介质为双绞线。光致动器和所有必需的控制设备应安装在中间天花板上，并且场景面板和占用开关应齐平安装在墙上。两种灯均为230 V卤素灯，并且需要相应的光致动器。
图3.自动生成抽象设计
C.自动生成抽象设计
接下来，将基于模板的需求转换为抽象设计。抽象设计已经在逻辑层，但在通用，平台和独立于供应商的级别上显示了类似基于功能块的结构，该模型使用新兴的德国标准VDI 3813作为房间自动化系统的通用表示形式，以实现功能集中的规划阶段以及政府经常要求的独立于招标的供应商招标。图1和图3中VDI 3813的最新草案引入了用于抽象设计的表示形式。该标准旨在集成到国际标准组织16484-4 [27]中。
需求的转换是使用通用编程（见II-C节）完成的，该编程已扩展到AUTEG [28]中的特定问题。如图3所示，它使用生成器将遵循通用构造计划和之前OWL中指定的功能要求的抽象功能块的抽象设计进行组合，每个构造计划代表许多设计模式，这些设计模式由VDI 3813功能块构图组成，以实现各种功能（如照明）。施工计划和功能块作为活动元素（AE）存储在活动库中，该库也基于OWL和SWRL。主动库不太容易出现库缩放问题，因为AE的特征参数会根据要求改变生成的抽象设计的特定形状。因此，相同的单个AE可以通过更改参数设置来覆盖许多不同的功能块变体。
例如，一个AE定义了灯光控制的形状，可以是自动灯光（不可调光；取决于占用率），亮度可调节的自动光（不可调暗；取决于占用率和亮度）或恒定光控制（通过一个参数并根据要求，选择三个功能之一以及所有其他必需的功能块，从而获得所需的功能块构图。
D.语义设备描述和组件存储库
从抽象设计到详细设计的自动过渡需要有关设备的其他信息以及有关在设备上实现的配置文件的特定语义知识。这包括有关每个配置文件实现的特定功能的知识（例如，恒定照明，自动照明和占用控制），应如何配置文件，其输入和输出数据点的目的（比标准变量类型更精确）以及如何实现这些配置正确连接。
系统集成商可以通过阅读制造商提供的设备手册来获取相关信息。但是，设备手册使用的是自然语言，对于计算机而言不容易理解。另一方面，已建立的设计工具使用的电子设备描述是机器可读的，但是缺少必需的语义信息，因为它们仅列出设备接口（配置文件，数据点和配置参数）。因此，现有资源不足以进行自动化设计。
因此，在AUTEG项目中开发了一种新的BAS设备和配置文件的语义描述[29]。利用OWL本体的优势，可以以计算机可理解的形式对所提到的知识进行正式规范。OWL的另一个好处是它本身就支持可扩展标记语言（XML）的序列化。因此，可以轻松地基于文件指定ABAS设备及其配置文件，并以XML格式开放可读。作为有价值的功能，
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[425580]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
