源基础设施数据与BIS概念模式的对齐的制作方法

本公开一般地涉及基础设施建模，并且更具体地涉及用于将源基础设施数据对齐以与概念模式兼容的技术。

背景技术：

遍及基础设施（例如，建筑物、工厂、道路、铁路、桥梁、电气和通信网络等）的设计、建造和运营，常常希望使用基础设施建模应用来对基础设施进行建模。此类基础设施建模应用常常使用各种不同的技术和数据格式来维护在基础设施项目的不同阶段中使用的基础设施描述。通常，根据此类格式维护的基础设施信息是脱节的，并且包括大量的数据冗余、不一致和其它效率低下的来源。可以针对特定的用例对模型进行优化和适配，而通常不考虑基础设施项目的其它阶段，从而导致不同的产品/学科/阶段数据竖井（datasilo）和不连贯的工作流程。

需要能打破此类现有的产品/学科/阶段数据竖井并能够实现现实世界基础设施的真正“数字孪生（digitaltwin）”的生成的技术，所述“数字孪生”以更统一的方式描述基础设施的方面。然而，即使可以开发出对现实世界基础设施的统一数字描述，但是期望行业放弃对使用现有的脱节技术和数据格式的软件所做的投资是不切实际的。需要技术来允许在工作流程中与现有的应用以及它们的脱节的技术和数据格式的不同合集一起利用统一的数字描述。

尽管存在（或可开发）各种转换器来将以一个格式（根据一个技术）存储的数据转译成另一个格式（根据不同的技术），但是常规的转换器不适合于该挑战。常规的转换器可允许另一个应用读取由第一应用创作的基础设施数据，但是通常不允许该应用理解转换后的基础设施数据或将它自己的数据与转换后的数据有意义地组合，因为由第一应用创作的数据的含义常常只隐含在创作程序中，而未以存储格式进行表达。此类转换不提供“对齐”，其中以新的数据格式准确地表达源数据的含义，以准许有意义的使用。这阻碍了源数据的使用，并且可能导致显著的效率低下。

需要的是用于将源基础设施数据对齐以与遍及基础设施项目的各个阶段充当现实世界基础设施的“数字孪生”的统一数字描述兼容的技术。

技术实现要素：

提供用于将源基础设施数据对齐以与通过下层（underlying）数据库模式（例如，dgndb）实现的概念模式（例如，构建的基础设施模式（bis））兼容的技术。根据概念模式对齐的数据可充当可遍及基础设施项目的各个阶段使用的现实世界基础设施的“数字孪生”，其中物理信息充当“骨干”，并且相对于它们维护非物理信息（例如，分析信息、功能信息、信息性信息（informationalinformation）等），形成内聚的整体（cohesivewhole），同时避免不必要的数据冗余。可提供源格式特定的桥接软件过程，所述源格式特定的桥接软件过程知道如何读取和解译各自源格式的源数据并用概念模式来表达它。可将对齐的数据发送给更新代理，更新代理解译对齐的数据并从中计算变更集（changeset），可存储该变更集以便最终应用于根据概念模式的下层数据库模式维护的数据库的特定实例。

在一个特定实施例中，使用源格式特定的桥接软件过程来将源基础设施数据对齐以与提供现实世界基础设施的统一数字描述的概念模式兼容。源格式特定的桥接软件过程检测到在一个或多个外部数据库或源文件中的基础设施描述的源数据自上一次对齐以来的变更，并且响应于检测到变更，至少读取变更后的源数据。桥接软件过程将变更后的源数据与概念模式对齐，以产生符合概念模式的描述。对齐可使用一个或多个模式映射，并且涉及诸如下列操作的操作：生成表达变更后的源数据的元素、模型和方面；选择将变更后的源数据分类为与建模视角相关联的元素和模型的类型；生成描述变更后的源数据的使用的角色元素；创建将变更后的源数据的元素、模型和方面联系起来的关系；将来自源坐标系的空间数据变换到由概念模式使用的空间坐标系中；和/或将来自源单位制的单位标签（unitlabel）变换到由概念模式使用的单位制中。然后，更新代理计算变更集。基础设施建模中心服务存储该变更集以便最终应用于根据概念模式的下层数据库模式维护的数据库的特定实例，以更新其中的基础设施描述。例如，可由客户端使用来自数据库的特定实例的数据库条目，以作为基础设施项目的设计、建造和/或运营阶段的部分显示更新后的基础设施描述的可视化或分析更新后的基础设施描述。

应理解，除了该发明内容中论述的那些特征和实施例之外，还可实现各种额外的特征和备选的实施例。该发明内容仅仅旨在作为对读者的简要介绍，并不指示或暗示本文中提到的示例涵盖本公开的所有方面或者是本公开的必要或本质的方面。

附图说明

下文的描述涉及示例实施例的附图，附图中：

图1是示例基础设施建模软件架构的至少一部分的高级框图；

图2是示出概念模式的示例按层次（hierarchically）分层的域的框图；

图3是示例数据库模式（例如，dgndb）的一部分；以及

图4是示出由软件过程执行的用于将源基础设施数据对齐以与概念模式（例如，bis）兼容并将该数据写入到利用下层数据库模式（例如，dgndb）的一个或多个公文包（briefcase）的示例操作序列的流程图。

具体实施方式

定义

如本文中所使用的，术语“基础设施”是指在现实世界中已经建造或计划建造的物理结构或对象。基础设施的示例包括建筑物、工厂、道路、铁路、管网等。

如本文中所使用的，术语“构建的基础设施模式”或“bis”是指描述表示基础设施的数据语义的一种类型的概念模式（即，概念数据模型）。可使用下层数据库（例如，sqlite数据库）来实现bis，其中bis中的结构映射到数据库的下层数据库模式（例如，dgndb）。

如本文中所使用的，术语“基础设施建模储存库（infrastructuremodelingrepository）”或简称“储存库”是指分布式数据库。分布式数据库的每个构成数据库可称为“公文包”，如下文所论述。

如本文中所使用的，术语“变更集”是指捕获将特定公文包从一个有效状态变换为新的有效状态所需的变更的持久电子制品（artifact）。当变更发生时，可通过记录对公文包所做的变更来生成变更集。捕获将公文包从一个状态（例如，状态m）移动到另一个状态（例如，状态n）所需的变更的变更集可被应用于处于状态m的公文包的副本，以将它更新到状态n。变更集也可被“反过来（inreverse）”应用，以将处于状态n的公文包变换回到状态m。

如本文中所使用的，术语“公文包”是指实现bis的数据库（例如，sqlite数据库）的特定实例。当将公文包用作储存库的构成数据库时，公文包表示储存库的特定版本的信息的物化视图（materializedview）。将处于某个状态（例如，状态m）中的储存库定义为由对“基线”公文包（例如，空的“基线”公文包）按顺序应用一直到并且包括变更集m的所有变更集而产生的信息。可通过对持有（hold）储存库的版本m的公文包应用从n到q（包括n和q）的变更集的集合来将该公文包更新为储存库的另一个版本（例如，版本q）。

如本文中所使用的，术语“元素”是指在公文包中维护的记录。元素表示（即，从术语的通俗意义来说是“建模”）现实世界中的实体（例如，泵、梁（beam）、合同、公司等）。表示现实世界中的基础设施实体（例如，管道、泵、梁、支持物等）的元素在本文中称为“基础设施元素”。

如本文中所使用的，术语“方面”是指属于特定元素、但是具有独立的生命周期（例如，可能在元素的生命周期中来来回回）的特性的集合。在一个实施例中，各个方面可由各个元素拥有，但是不可单独标识，并且除了来自拥有它的元素之外，没有传入（incoming）关系。

如本文中所使用的，术语“模型”是指在公文包中维护的元素的集合的容器，所述公文包中元素的集合共同表示（即，从术语的通俗意义来说是“建模”）现实世界中的实体。现实世界中的实体可以是基础设施的单个单元。在一个实施例中，模型可嵌套。即，模型被说成将特定元素（例如，基础设施元素）“分解（breakdown）”成更细粒度的描述（即，描述现实世界中的相同实体但是以细粒度描述的描述）。

如本文中所使用的，术语“关系”是指将两个或更多个元素、方面或模型联系起来的连接。关系的示例包括可暗示所有权的父-子关系和可定义群组的对等关系。

示例实施例

图1是示例基础设施建模软件架构的至少一部分的高级框图。可将该架构划分成为了企业的使用托管或本地布置内部部署的（on-premises）一个或多个计算装置（统称为“客户端装置”）上执行的客户端侧软件110，以及在该企业和其它企业通过因特网可访问的一个或多个远程计算装置（“云计算装置”）上执行的基于云的服务软件120。

基于云的服务软件120的核心是基础设施建模中心服务（例如，imodelhub服务）130，它们提供集中式管理和同步支持，并且与提供冲突检测、验证、成本计算、发布、分析等服务的公文包服务140密切合作。基础设施建模中心服务（例如，imodelhub服务）130维护储存库132-134，所述储存库132-134包括公文包152、接受变更集（例如，历史变更集）的集合154、元数据156（例如，其包括关于变更集的存储位置、查找标识符、序列信息等）和锁158（例如，其可给每个元素和每个模型提供悲观锁定（pessimisticlocking））。储存库132-134中的公文包152可作为空的“基线”公文包开始，该空的“基线”公文包以编程方式生成，并且可由基础设施建模中心服务（例如，imodelhub服务）130来持续。可通过将新的变更集接受到接受变更集的集合154中来修改储存库132-134。可由记录对公文包所做的修改的实际和具体影响的变更检测功能性来创建变更集。如果新的变更集持有相对于具有储存库的信息的最新版本的公文包的变更，则该新的变更集才可作为对储存库的修改被接受（即，接受到接受变更集的集合154中）。随着接受变更集的集合154中的变更集的数量增长，进行以下操作所要求的时间可能会变大：取空的“基线”公文包并应用将它变换为特定版本（例如，“最新版本”）的公文包所需的所有变更集。出于这个原因，基础设施建模中心服务（例如，imodelhub服务）130可创建不同版本的额外的“快照”公文包152。当需要公文包的特定版本（例如，“最新版本”）时，访问最接近于该版本的公文包152（它可以是“快照”公文包），并应用来自集合154的变更集（或反向变更集），直到获得所需版本的公文包152为止。

可为了企业的使用托管或在企业的桌面型或移动计算装置上本地执行客户端150。每个客户端150可利用基于超文本传输协议（http）的代表性状态传输（rest）应用程序接口（api）来与基础设施建模中心服务（例如，imodelhub服务）130通信，以获得本地公文包和将它变换为储存库132-134的希望版本的公文包所需的变更集。客户端150可订阅由基础设施建模中心服务（例如，imodelhub服务）130提供的通知功能，以接收关于储存库的接受变更集的集合154中的新变更集的通知。然后，客户端150可“拉（pull）”（下载）（一个或多个）新的变更集，并将它们应用于它的公文包，以将公文包更新到新版本。当客户端150修改公文包时，类似的操作可发生，以传播那些变更。当客户端修改公文包的版本（例如，版本x）而导致经修改的公文包具有临时的新版本号（例如，临时的新版本y）时，根据修改生成新的临时变更集（例如，临时变更集y）。然后，将临时变更集y“推（push）”（上传）到建模中心服务（例如，imodelhub服务）130。如果变更集x仍然是已被接受到储存库的接受变更集的集合154中的最新变更集，则临时变更集y被接受到接受变更集的集合154中并且变成新的“最新变更集”。否则，客户端150可“拉”（下载）任何更新的（一个或多个）变更集，并将它们应用于它的公文包并协调由该更新创建的任何不一致。在这个“拉和合并”过程完成之后，客户端150可尝试将更新后的临时变更集“推”（上传）到基础设施建模中心服务（例如，imodelhub服务）130。

除了这个操作之外，基础设施建模中心服务（例如，imodelhub服务）130可从其它服务接收调用（call）并支持额外的功能。例如，web访问服务142可调用基础设施建模中心服务（例如，imodelhub服务）130作为将在公文包152中维护的基础设施的实时视图或发布的视图提供给作为门户客户端154操作的某些实践者应用的部分。门户客户端154可基于web，在桌面型或移动计算装置上被本地执行或者被托管，经由基于http的restapi与公文包服务140和基础设施建模中心服务（例如，imodelhub服务）130通信。此类门户客户端154一般不维护本地公文包，而是相反依赖于到web访问服务142的连接性。信息服务180管理资产数据、项目数据、现实数据、物联网（iot）数据、代码和其它特征。企业系统182管理存储企业特定的数据的现场的或托管的企业数据库183。此外，应用即服务平台184提供洞察力（insight）、交付物管理、包管理以及各种其它服务。

某些外部应用（一般称为“传统客户端（legacyclient）”）156可依赖于不同的技术和数据格式来维护基础设施描述。此类格式可包括多个长期利用的数据库和文件格式，诸如dgn、dwg、rvt、ifc等。传统客户端156可通过利用文档管理系统172签出（checking-out）、修改、并且然后签回到文件173中或者通过读取不同的数据库条目并且然后将其写回到外部数据库174来对数据做出变更。为了支持此类传统客户端156，桥接服务（bridgeservice）170可与基础设施建模中心服务（例如，imodelhub服务）130一起合作，以递增地将在由文档管理系统172管理的源文件173中和/或在按照源格式的外部数据库174中的数据（即，“源数据”）对齐以与概念模式（例如，bis）兼容。为此，该桥接服务170包括多个源格式特定的桥接软件过程176，每个过程176都知道如何读取和解译各自源格式的源数据并用概念模式（例如，bis）来表达它。如下文更详细地解释，桥接软件过程176可在检测到源数据中的变更时响应性地执行、独立地执行并且潜在并行地执行。

概念模式（例如，bis）提供了一种以统一的方式描述从设计到建造和运营的基础设施项目的各个（例如，所有）阶段中基础设施的所有面的方式。以此方式，概念模式可以是现实世界基础设施的“数字孪生”，作为内聚的整体操作，同时避免不必要的数据冗余（即，重叠的信息）。物理信息可充当“数字孪生”的“骨干”，并且可相对于（例如，增加）“骨干”维护非物理信息（例如，分析信息、功能信息、信息性信息等）。根据概念模式（例如，bis）维护的数据的结构和含义可在数据本身中明确。各种各样不同的建模、分析和可视化软件程序能够读取和理解根据概念模式维护的数据并根据它创建新的数据。因此，概念模式可解决与组合和解译使用各种供应商特定、学科特定或行业特定的技术和数据格式写入的数据有关的问题，打破传统上已经分离的数据“竖井”之间的壁垒。

可将概念模式（例如，bis）构造为一系列按层次分层的域。每个域为主题的自然一致且有限的集合定义类别和数据类型，其可具有清晰的范围和所有者。可基于主题的通用程度或专门化程度来按层次对这些域进行分层。图2是示出概念模式（例如，bis）的示例按层次分层的域的框图200。在最低层（“核心”层），单个核心域可定义所有其它域必须遵循的核心类别和组织策略。在核心层上方的下一层（“公共”层）220，公共域可定义适用于多个工程学科的数据类型和组织策略。公共域的示例可以是“建筑物”公共域，它包括与建筑物质量（诸如，楼层）有关的类别和组织策略，但不包括架构（诸如，窗）或结构（诸如，梁）的更低级细节。在公共层上方的进一步层（“互操作”层）230，互操作域可定义适用于工程学科之中的互操作性的数据类型和组织策略。示例互操作域可描述可允许其它学科定义所要求的电气服务（例如，对于泵、电梯、服务器机房等）的电气特性，诸如负载。在互操作层上方的更进一步层（“物理”层）240，物理域可定义适用于现实世界物理实体的数据类型和组织策略。在物理层上方的又一甚至更高层（“功能/分析”层）250，功能/分析域可以为用于启用图表和仿真的功能或分析数据定义数据类型和组织策略。在功能/分析层上方的最后一层（“应用”层260），小型应用域可定义有限数量的数据类型，以用于由特定应用软件访问。

概念模式（例如，bis）描述由用于存储所有基础设施信息的元素、方面、模型和关系构成的组构（fabric）。可以单独标识和锁定的最细粒度的记录是元素，它表示（即，从术语的通俗意义来说是“建模”）现实世界中的实体。元素可能不固有地是几何的，并且在一些情况下可能不包含几何信息。在一个实施例中，可定义三种类型的元素，所有其它元素都可从它们转变而来：几何元素、信息元素和角色元素。

几何元素可将现实世界中的任何实体表示为固有地是几何的（使得可要求它以图形方式显示），并且可包括在几何上下文中的绘图图形（例如，线弧、圆等）以及物理实体（例如，泵、梁等）。可根据2d分支（例如，包括2d几何类别、2d图形类别和绘图图形类别）和3d分支（例如，包括3d几何类别、3d图形类别、空间类别、物理类别和空间位置类别）来按层次定义几何元素。

信息元素可以是某个现实世界信息实体的信息的载体。信息元素的示例是携带关于物理实体（例如，泵、梁等）的“要求”（例如，流速、承载能力等）的信息的要求元素。可根据定义分支（例如，包括图形2d类型类别和物理类型类别）和文档分支（例如，包括绘图类别）来按层次定义信息元素。

角色元素可表示物理实体在不同域中的使用，并且允许共享和利用公共信息。角色元素可通过物理元素链接到其它角色元素。例如，考虑可在不同系统中同时扮演许多角色的一块黄金（例如，它可充当热导体、金融价值的贮存品（store）、艺术品等）。所有这些“角色”都可由通过表示黄金的物理块的物理元素连接的角色元素来表达。

可通过暗示所有权和级联删除（例如，当删除父代（parent）时，也删除它的子代（children））的一系列父-子关系来按层次组织元素。通常，元素最多可具有一个父代，但是可具有多个子代。作为父代的元素可视为是它的所有子代的总成（assembly）。父-子层次中的所有元素通常驻留在相同模型中。由于层次中可以有多个级别，所以可以有总成的总成。

概念模式（例如，bis）的方面描述属于特定元素、但是具有独立的生命周期（例如，可能在元素的生命周期中来来回回）的特性的集合。方面通常不可单独标识，并且除了来自拥有它的单个元素之外，缺少传入关系。在一个实施例中，可定义两种类型的方面：元素唯一方面和元素多方面。元素唯一方面可以是当有由单个元素拥有的零个或一个方面时的类别，而元素多方面可以是当有由单个元素拥有的零个、一个或多个方面时的类别。

概念模式（例如，bis）的模型是元素的集合的容器，其中元素的集合共同表示（即，从术语的通俗意义来说是“建模”）现实世界中的实体。模型拥有它所包含的元素，并为这些元素提供上下文。每个元素包含在单个模型中。除储存库模型之外，每个模型表示（即，从术语的通俗意义来说是“建模”）某个元素（它不包含在该模型中），如下文更详细地论述的那样。

可根据模型层次来布置模型，以从多个视角（包括多个粒度）支持建模。对高级实体进行建模的单个“储存库模型”可充当模型层次的根。储存库模型包括可按层次组织的一个或多个主题。包括描述储存库模型是关于什么的单个根主题（即，不具有父代的主题）。储存库模型还可包括一个或多个子主题（即，具有另一个主题作为父代的主题），这些子主题命名由“根主题”命名的实体的部分或与由“根主题”命名的实体密切有关的实体。每个主题（或者根主题或者子主题）具有使用父-子关系与它相关联的一个或多个信息分区。每个信息分区表示特定的建模视角，该建模视角指示要建模的主题的面，例如物理、功能或某个其它角色。物理信息分区表示物理建模视角；分析信息分区表示分析建模视角；信息性信息分区表示信息性建模视角等。一个或多个子模型与每个信息分区相关联。每个子模型包含一个或多个元素，这些元素使用由该模型是子代的信息所指示的建模视角来表示在主题中命名的实体。物理信息分区可以是主题的子代，并且作为该分区的子代的物理模型可表示由主题命名的实体的物理属性。分析模型可表示分析信息，并且包含表达关于在特定条件下的性能或其它特性（例如，结构完整性、热性能等）的分析数据的元素。类似地，信息性模型可表示信息性信息，并且包含表达相关信息（诸如，可得到的组件或设计规范）的元素。应理解，可提供各种各样额外的信息分区和模型。

概念模式（例如，bis）的关系是将两个或更多个元素、方面或模型联系起来的连接。关系的示例包括暗示所有权的父-子关系和定义群组的对等关系。在一个实施例中，可提供两种类别的关系，其中抽象关系禁止实例化但准许从其继承，以及密封关系（sealedrelationship）禁止从其继承。继承关系可通过提供相等或更特定的源和目标和/或相等或更严格的基数来使关系变窄。

如上文所论述，概念模式（例如，bis）可通过下层数据库模式（例如，dgndb）实现。下层数据库模式可规定由公文包152使用的各个表和表（例如，sqlite表）的列和行。图3是示例数据库模式（例如，dgndb）300的一部分。在数据库模式300中，模型表310的行表示模型。模型表列可包括模型id和代码列。元素表320可包括表示元素的行。元素表列可包括元素id列、代码列、模型id列（例如，引用模型表310的行）、分类id列（例如，引用分类表340的行）和几何列（例如，引用元素几何表330的行）。元素几何表330的行可表示引用元素的几何方面。元素几何表330的列可包括放置列、大小列和几何流。元素几何表行可引用子分类表350的一个或多个行。分类表340的行可表示分类。分类表340的列可包括元素id列和代码列。子分类表350的行可表示子分类。子分类表350的列可包括子分类id列、代码列、分类id列（引用分类表340的行）和外观列（诸如，颜色列、重量列和样式列）。此外，视图表360的行可表示图形视图。视图表360的列可包括查看的模型列（例如，引用模型表320的一个或多个行）、查看的分类列（例如，引用分类表340的一个或多个行）和子分类覆写（override）列（例如，通过引用子分类覆写表370的一个或多个行）。应理解，数据库模式（例如，dgndb）还可包括用于实现概念模式（例如，bis）的多个额外的和/或不同的表、列和行。

如上文所提到的，为了支持传统客户端156，桥接服务170的桥接软件过程176可以与基础设施建模中心服务（例如，imodelhub服务）130一起合作来将源数据对齐以符合概念模式（例如，bis）。此类对齐不仅可重新表达源数据以使它符合概念模式，而且还可重新表达为主题的自然一致且有限的集合定义类别和数据类型的所述概念模式的特定域。此类对齐的净影响是要将源数据转译成可在现实世界基础设施的内聚“数字孪生”中有意义地使用的形式。

图4是示出由软件过程执行的用于将源基础设施数据对齐以与概念模式（例如，bis）兼容并将该数据写入到利用下层数据库模式（例如，dgndb）的一个或多个公文包152的示例操作序列的流程图。最初，传统客户端（即，外部应用）156通过对变更源文件173的文档管理系统172写入或通过写入/变更外部数据库174来变更根据它的源格式维护的数据。源格式可能没有显式的模式，或者它的模式可能隐含在传统客户端的代码中。文档管理系统172或外部数据库174可响应于这些变更而触发事件410。事件410使得源格式特定的桥接软件过程176运行。如上文所提到的，可以有多个不同的桥接软件过程176，每个桥接软件过程适应（tailor）于不同的各自源格式，并且每个桥接软件过程可在需要时独立执行（潜在并行地执行）。

触发的桥接软件过程176可支持增量对齐，使得在运行时，它发起对自上一次对齐以来已经变更的源数据进行对齐的操作序列，但是不影响已经维持不变的源数据。在一个实施例中，通过维护自上一次成功对齐以来的条件信息的同步信息记录来启用变更检测。即使在文档管理系统172和文件173或外部数据库174具有有限的能力（例如，仅仅能够枚举它的内容，而不能标识自上一次成功对齐以来的特定变更后的内容）时，同步信息记录也可能够实现增量对齐。

触发的桥接软件过程176使用源格式特定的访问库或应用420来从文档管理系统172的文件173中或从外部数据库174中至少访问变更后的源数据。此类库或应用可遵循源格式的读取约定。桥接软件过程176理解源数据的含义以及如何用概念模式（例如，bis）来表达它。桥接软件过程176可进一步理解如何利用概念模式的相关域模式，使得可变换该源数据以为它所属的主题的集合占据合适的类别和数据类型。

为此，触发的桥接软件过程176执行对齐操作，以使变更后的源数据符合概念模式和相关域模式。对齐可包括多个子操作。例如，可生成元素、模型和方面以表达变更后的源数据。可选择元素和模型的类型，使得将变更后的源数据明确地分类为与（例如，物理的、分析的、信息性的等）建模视角相关联。可生成在整个基础设施描述中描述变更后的源数据的使用的角色元素。此外，可创建使生成的元素、方面或模型彼此之间以及与现有的元素、方面或模型有关的关系。可定义高级组织结构，诸如主题。可将来自源坐标系的空间数据变换到由概念模式使用的空间坐标系中，并且可将单位标签从源单位制变换到由概念模式使用的单位制中。

为了进行对齐操作，触发的桥接软件过程176可产生使源数据格式与概念模式及其域模式有关的模式映射。此外，触发的桥接软件过程176可以规划空间变换和单位制变换。模式映射和空间/单位制变换可在将按照源格式的源数据初始对齐以符合概念模式和域模式时被生成，并且随后可在对源数据的变更要求后续增量对齐时被访问和利用。

尽管触发的桥接软件过程176负责检测变更、至少读取变更后的源数据并将变更后的源数据对齐以符合概念模式（例如，bis）和域模式，但是它可能不牵涉到下层数据库模式。为此，触发的桥接软件过程176可将对齐后的数据发送到更新代理430。更新代理430可采取由桥接软件过程176远程调用的web服务的形式，或者备选地可采取可与桥接软件过程176组合并由桥接软件过程176直接调用的库的形式。更新代理430可解译对齐后的数据并从中计算变更集（例如，sqlite变更集）440，可将该变更集应用于公文包，以利用数据库模式（例如，dgndb）的约定将公文包从先前的状态转变为新的状态。在一个实施例中，更新代理430通过在变更检测功能性开启的情况下将数据写入到公文包的私有副本来计算变更集440。写入数据可能需要执行数据库修改命令的序列，诸如行的插入、更新和删除等。写入数据还可能需要修改公文包本身的结构，诸如插入新的表或将新的列插入到现有表中。变更检测功能性记录修改命令对私有副本的实际和特定影响，积累这些影响的记录。然后，以可用于重新创建变更的变更集440的形式保存记录。

可将变更集440发送到基础设施建模中心服务（例如，imodelhub服务）130（例如，imodelhub服务），基础设施建模中心服务130可存储变更集以便最终应用于公文包152，以将公文包更新为新的版本。此类更新可协调由客户端150、154使用的基础设施描述（例如，用于可视化、分析等）与由传统客户端156使用的基础设施描述，因此它们都将看到相同的基础设施信息。

总之，上文的描述详述了用于将源基础设施数据对齐以与概念模式（例如，bis）兼容的技术。概念模式可充当现实世界基础设施的“数字孪生”，其中物理信息充当“骨干”，并且相对于它们维护非物理信息（例如，分析信息、功能信息、信息性信息等），形成内聚的整体，同时避免不必要的数据冗余。应理解，数据冗余可能消耗过多的存储空间（即，引入存储效率低下），并且可能消耗额外的处理功率来独立地访问和操纵（即，引入处理效率低下）。除了其它益处之外，上文描述的技术还可通过减少此类存储和处理效率低下来改善客户端装置和云计算装置两者的机能，以改善此类电子装置的机能。

应理解，可对这些技术进行各种各样的适配和修改。例如，尽管上文描述的是，通过单个下层数据库模式（例如，dgndb）来实现概念模式（例如，bis），但是应理解，在备选实施例中，可以用多个下层数据格式来实现概念模式。例如，各个桥接软件过程176可配置成将数据对齐到不同“聚焦的（focused）”下层模式。

一般来说，应记住，可以用软件、硬件或其各种组合来实现功能性。软件实现可包括存储在诸如易失性存储器、持久存储装置或其它有形介质的非暂时性电子装置可读介质（例如，非暂时性计算机可读介质）中的电子装置可执行指令（例如，计算机可执行指令）。硬件实现可包括逻辑电路、专用集成电路和/或其它类型的硬件组件。此外，组合的软件/硬件实现可包括存储在非暂时性电子装置可读介质中的电子装置可执行指令以及一个或多个硬件组件两者。最重要的是，应理解，上文的描述意在只作为示例。