用于监控过程和/或制造设备的方法与流程

本发明涉及一种用于监控过程和/或制造设备的方法，该过程和/或制造设备包括多个组件并且是借助于多个工程系统计划而成的。此外，本发明还涉及一种用于监控过程和/或制造设备的装置。

背景技术：

目前，在通过设备跨系统地处理信息的方面还存在极大的缺陷。以标准形式存在的且可进行电子分析的“竣工(as built)”设备文件始终还是只有在特殊情况下才能获得。特别是当有配件供应商参与时、例如当配件供应商参与物流或者在交通技术上有所参与时尤其如此。如今，基于工程设计中系统环境的异质性，由配件供应商方面创建的文件、数据和程序不能自动地相互关联，这必须耗费高昂的投入由人工完成。由此，不仅对数据的预处理成问题，而且特别是其时效性和一致性也难以得到保证，因为没有可供此用的统一机制。

市面上不仅缺少能够从工程过程出发对结果进行管理并保持其时效性的产品，甚至连理念基础都很匮乏。对此的例子有确保一致性、融合利益相关者、跟踪通过维护和保养工作在设备上产生的变更、对“竣工”状态进行统一的版本管理和等等类似措施。如果能够通过合适的方案解决这一难题-并且此外还将现有的产品花色品种整合到一起-那么对于消费者来说将会产生明显的增值。特别是对于运行管理阶段来说、即对于服务和维护行为来说容易产生该问题，但在进行原因分析时也同样如此。

如今用于诊断过程数据的或用于使其可视化的系统也被称作数据采集与监控系统(SCADA-Supervisory Control and Data Acquisition)，这种系统通常对设备本身没有任何了解。当需要用到这种关联时，必须将其在相应的系统中完全程序化(ausprogrammiert)。对此的例子有压缩空气管道中泄漏位置的识别，在进行识别时，通常不必使用传感装置来较为精确地界定泄漏位置。而是分析生产商和使用方的报告并且尝试藉此形成有关该系统的推断。目前来说，为此必须以程序的形式储存拓扑结构，这会导致这样的结果，即在设备发生变更后，必须对程序进行分析和修改。而当设备的拓扑结构可供就地进行分析时，则可以跨越相应管道并使生产商和使用方相互关联，从而能够进行类属诊断。

传统的方式是，在工程系统之间通过输入和输出过程交换数据并且每个系统本身创建一部分设备文件。文件的时效性和一致性能够用人工操作来保证，这特别是因为在制造设备时(所使用)的大多数工具中都没有进行版本管理。文件(除了自动化和控制技术软件外)通常以PDF或TIFF文档的形式存在并且不能做进一步分析。通常为运行管理本身提供单个系统，例如维修、维护和检修(MRO-Maintenance,Repair and Overhaul)系统或诊断系统。通常必须向这些系统中输入工程系统的文件和/或数据。但并未因此而存在跨应用的或跨行业的模板。此外也无法从这些数据和文档中推导出拓扑结构。

文件管理系统(DMS系统)则是在工程系统文件的基础上建立的。这些DMS系统也支持进行文档可视化。部分地存在这样的系统，即事后扫描文档并通过标签建立文档层面上的链接(例如为了创建计算机管理零件目录)。在此，除了文档外还附加地储存版本说明、批准书(Freigabe)或类似文件。但对于DMS系统来说，在任何情况下都无法用机器分析设备的拓扑结构。

产品管理系统(PDM)则又将工程系统视为核心的信息转盘，也就是说，在此将原始系统用作文件。用于制造产品的系统通常也具有可视化功能。在此检测计算机辅助设计(CAD-Computer Aided Design)数据和企业资源计划(ERP-Enterprise-Resource-Planning)数据。存在这样的方案，即将该方法转用到设备制造上，也就是说，将工程系统和数据也一并转交给设备的使用方并且将其包括在运行管理中，如果应用的是例如PDM系统，这则是不可能实现的。

在工程系统COMOS中，MRO系统直接使用原始工程数据，MRO系统近似于是对计算机辅助工程(CAE-Computer Aided Engineering)系统的功能性扩展。但这一工具仅被设想用于过程工业。对于在传统上非常多的配件供应商被捆绑在一起的制造业来说，这类工具是未公开的。该方案的缺点在于，同样不能对这种工程工具进行优化以便用于运行管理以及用于工程设计。技术保护同样也难以实现。此外，它仅能提供由其集成在自身的工程工具中的数据的镜像。外部系统的数据则必须由人工输入并使其与数据模型相适应，这更增加了保持时效性和一致性的难度。另一问题在于，在制造设备时必须通过这种工具实现不同的目的设置。通常情况下，这是一种非常昂贵且高风险的方法，因为须将异质的工程系统在通常是历经多年才形成的完全的功能范畴内置于一个共同的平台上。在这方面进行的多次研究过去都失败了，因为基于研究计划的持续时间，这些研究必须为客户对现有的工程系统同样在功能上加以扩展，并且新系统的实施也由此变得越来越困难，其费用也越来越高昂。在许多情况下，这种平台式的方案也已不再是“单项优势方案(best of breed)”，而且许多消费者也不愿仅单独依靠一家配件供应商。

此外还有这样的方案，即：使基础模型标准化并且使符合标准的产品相互兼容，从而能够(例如利用STEP程序)至少进行普遍的数据交换。但在这方面做出的许多努力也均折戟，原因特别是在于，工程工具的制造商不希望其工程工具能够相互交换数据。但仍须一致遵守的是，这些模型主要致力于工程工具的相互协调，而非运行管理的优化。

技术实现要素：

本发明的目的在于，提出一种能够更简单有效地监控过程和/或制造设备的方法。

该目的通过根据本发明的方法和装置实现。本发明的有利的改进方案在以下进行说明。

根据本发明的、用于监控包括多个组件并借助于多个工程系统计划而成的过程和/或制造设备的方法包括利用工程系统中的第一工程系统提供组件中的至少一部分的第一结果数据，利用工程系统中的第二工程系统提供组件中的至少一部分的第二结果数据，从第一和第二结果数据中提取描述在过程和/或制造设备内部的组件的布置的拓扑数据和组件的运行数据，并通过拓扑数据和运行数据为该过程和/或制造设备建立模型。

工程系统提供用于计划和制造过程和/或制造设备的不同工具。这些工具能够例如通过相应的程序来提供。工程系统能够通过CAE应用程序来提供，不同的CAE应用程序相应地涉及设备的不同的技术方面。由工程系统分别提供结果数据。在此可以考虑应用在CAE系统中用于修改的原理。它们是-经简化示出-对于在内容上已通过测试并随后保存下来的数据的视图或报告。它们被用于有目的性地显示结果数据。由此能够利用这些结果数据来提供相应的工程系统的工程过程的镜像(Abbild)。该镜像首先显示设备的计划状态并且须与实际在设备上实施的以及使用的状态相区分。如果这些镜像是一致的，则能够在此基础上建立版本管理，利用该版本管理能够区分这些状态。其中，能够以用于计划设备的工程过程的顺序提供结果数据。结果数据能够以可从数据处理技术上进行分析的形式来提供。例如能够以XML格式提供结果数据。结果数据的使用简化了对数据的考察，这是因为这些数据通常不再是直接基于工程系统的内部数据保持，而是(例如以电路或接线图的方式)对其使用标准化的视角。

从该至少两个工程系统的结果数据中提取出描述设备组件之间的作用连接的拓扑数据。此外还提取出设备组件的运行数据。从拓扑数据和运行数据中能够逐渐建立设备的模型或者说设备的数字化镜像并且与设备当前的过程数据相关联。在此，也可以对拓扑数据和运行数据设有技术保护(Know-How-Schutz)。由此能够附加地防止出现第三方、例如配件供应商无法访问数据的情况。通过使用结果数据来代替工程工具的原始数据，便已隐性地存在一种技术保护，这是因为数据镜像通常不足以实施设备的工程设计。

这种模型能够用于对运行管理进行优化。从中期到长期来看，这种镜像能够导致基础的工程应用程序相互结合。它不仅能够导致形成统一的报告系统，而且也能够使这种镜像的特性逐渐进入应用程序的研究发展中，但同时应用程序也不必放弃其独立性。

优选地在模型的表示(Darstellung)中示出在过程和/或制造设备内部的组件的布置和相应组件的运行数据。在相应工程系统中进行的认可过程中，结果数据能够以矢量图的形式输出至附属的元模型中。其中，模型的表示可以这样构建，即设备组件作为表示中的对象是可以识别出和进行选择的。此外还在图形组件和例如在其中储存了组件的运行数据的元模型之间创建关联。

在一种实施方式中，将组件的相应的输入侧的和输出侧的作用连接由上至下地提取为拓扑数据。由此能够简单地检测到设备中的单个组件的连接并且以可靠的方式提供设备的模型或者说镜像。

在另一种设计方案中，提供了三维模型、管路图和/或电路图来作为工程系统的第一或第二结果数据。用于设计设备的工程系统可能涉及不同的技术领域。在此，仅仅只有工程系统的结果是能够借助于结果文件来使用的。由此，仅仅只有对于设备运行具有重要意义的数据被用于创建用于设备的数字化模型。

优选地提供组件的数据手册和/或运行参数作为工程系统的第一或第二结果数据。由此能够附加地将在设备中使用的相应组件的运行值集成在模型中，由此能够例如利用过程数据、例如运行小时数或警报使工程对象、例如发动机或泵相结合。工程系统能够在文件和操作方面为实现设备的项目化进行优化，而镜像则是能够设计用于运行管理阶段的。

在另一种实施方式中，从第一和第二结果数据中提取出的拓扑结构和运行数据被转化为预定的数据格式。结果数据能够设置为统一的形式，从而使用于查找和遍历(traversieren)数据的类属函数成为可能。由此能够统一地使用服务和诊断应用程序。

优选地是，附加地将来源数据也归入拓扑数据和运行数据中，来源数据用于描述拓扑数据和运行数据是否是从第一或第二结果数据中提取出来的。通过这种方式能够提供这样的来源数据，即利用该来源数据能够追踪数据来自于哪个结果文件以及来自于哪个工程系统。

优选地在模型中提供指向第一和第二结果数据的链接。由此能够提供可能性，即在考虑参考对象的情况下从数字化镜像中切换到基础的工程系统中。当例如组件在管路图的图解中选择时，则有可能切换至附属的、在其中产生了管路图的CAE应用程序。其前提当然是，这些应用程序在该设备上是可供使用的。

在另一种设计方案中，当第一和/或第二结果数据发生变化时，模型也进行相应调整。由此能够集成不同应用程序的或不同行业的数据，而不必在工程和/或运行时间系统中完全重新建立新的模型。

优选地在模型中显示第一和/或第二结果数据的变化。一般来说，即使工程系统无法做到对数据版本管理给予支持，但这也仍是能够实现的。模型的构建应该这样集成到工程过程中，即它能够保持其时效性和一致性。在此，设备上的更改-除了在工程过程中发生的更改-是能够检测到并传递到附属的工程系统中的。此外，服务和维护技术人员还能够一致地处理该设备模型。这特别地意味着，迄今使用的报告在关于其表示和内容方面能够以模拟的方式供人使用。

根据本发明的、用于监控包括多个组件并且借助于多个工程系统设计而成的过程和/或制造设备的装置包括用于接收工程系统中的第一工程系统的组件中的至少一部分的第一结果数据并且用于接收工程系统中的第二工程系统的组件中的至少一部分的第二结果数据的接收装置以及用于从第一和第二结果数据中提取描述在过程和/或自动化设备内部的组件的布置的拓扑数据和组件的运行数据的和用于根据拓扑数据和运行数据建立用于过程和/或制造设备的模型的计算装置。

与根据本发明的方法相关联地说明的改进方案可以套用在根据本发明的装置上。

附图说明

现在通过附图详细地说明本发明。图中示出：

图1示出用于检验过程和/或制造设备的装置的示意图；

图2示出过程和/或制造设备的模型的示意图；

图3示出示教器的示意图；和

图4示出用于检验过程和/或制造设备的装置的另一种实施方式的示意图。

具体实施方式

在后面详细说明的实施方式是本发明的优选的实施方式。

图1示出用于检验过程和/或制造设备12的装置10的示意图。该过程和/或制造设备12是由多个工程系统设计而成的。设备12当前是由六个工程系统14，16，18，20，22，24设计而成的。工程系统14，16，18，20，22，24涉及不同的技术领域。例如能够利用工程系统14提供管路和安装图。利用工程系统16能够提供电路图。利用工程系统18能够提供设备12的三维图。利用工程系统20能够提供关于设备12的组件44的数据手册。利用工程系统22能够提供用于可存储编程控制装置的连续功能图(CFC-Continuous Function Charts)。最后，利用工程系统24能够提供过程可视化功能。

当利用相应工程系统14，16，18，20，22，24对设备12进行的设计结束时，从工程系统14，16，18，20，22，24中的每一工程系统中输出相应的结果数据26，28，30，32，34，36。这些结果数据26，28，30，32，34，36被装置10的接收装置40接收。利用装置10的计算装置42提取描述组件44在过程和/制造设备12内部的布置的拓扑数据和组件44的运行数据。利用计算装置42从拓扑数据和运行数据中创建设备12的模型或者说数字化镜像。此外，装置10还具有用户界面46和用于连接其他服务的界面48，这些界面例如能够用于诊断服务或用于服务和维护相关的行为。

经过修改的报告和文件以结果数据26，28，30，32，34，36的形式根据工程过程的顺序而产生，这能够由此出发，即一开始便限定核心的关联组件并在后来增加信息。随后在形成修改版本时(例如在批准文件时)，该模型50也不言明地进行了更新或者说重构，从而使模型50能够无缝地关联到工程中。仅须对相应的报告或者说修改文件这样加以扩展，即结果数据26，28，30，32，34，36以可分析的格式传递出去。模型50不支持任何工程功能，但模型50却被优化用于跨行业和应用程序导航。此外，模型50还被用作统一的基础，以便独立于应用程序地对设备的计划状态和实际状态进行比较。工程数据必须通过原始工具来进行。对于数据的来回传输来说，则参阅原始数据和应用程序(来源证明)。通过统一地在元模型中对数据进行管理，也能够实现统一的功能，例如查询、报告、版本管理或类似功能。

图2在2D浏览器(2D-Viewer)的示意图中示出设备12的模型50。在第一视窗52中图解性地示出了设备12的单个组件44和其作用连接(在本图中即为管路和安装图)。在第二视窗54中列出了单个组件44。在这里能够这样示出工程系统14，16，18，20，22，24的结果数据26，28，30，32，34，36，即元模型和附属的示意图解之间的联系是可以跟踪的。例如能够在第二视窗54中选择设备等级中的组件44并且在第一视窗52中的与此相应的管路和工具化设计图中突出显示。此外，在第三视窗56中还能够显示所选择的组件44的运行值。

通过在工程过程中以结果数据26，28，30，32，34，36形式存在的文件和数据的不同的修改和发布(Freigaben)而逐渐形成设备12的部分镜像。这些部分镜像被用于隐性地对跨行业的模型50进行扩展和更新。为了实现数字化镜像，这些数据和文件被相互关联。此外，通过仅使用经过批准的数据和文件还实现了这一目的，即仅具有一定成熟度的信息才被收入模型50中。当不同的工作状态集结到一起时，令人担忧地是会一再出现相互不一致的状态，这会导致产生相应的附加投入。关于工程过程方面，预设了一定的顺序，这些文件和数据按照这一顺序形成。例如在对图中组件44的设备规格进行说明前首先创建管路和安装图(P&ID)。设备规格随后则与管路和安装图总的组件44相链接。

本质性的是，不是文件或图“本身”、而是这些资料的对象设有链接。例如必须存在这种可能性，即对于P&ID中泵来说，能够获得附属的其它文件、例如电路图，或者相应制造商的产品说明书，还有例如功率说明和临界值等数据。这些对象能够具有各不相同的-也可以是跨行业的-关联，例如泵和附属的CFC图之间的关联。镜像50为此必须具有类属(可扩展的)特点。

作为对此的基础，必须存在共同的(例如对于设备对象的)对象概念。普遍适用的是，在项目内部必须存在明确的论断，对象、图和文件根据这些论断而相互关联(例如通过在项目中适用的标号系统)。因此假定，这种关系能够通过规则自动生成，从而不必为产生模型50而耗费附加的工程功率。如果满足该假定条件而在特定的情况下基础信息不够充分以及有待从中推导出的规则太过复杂，则须向工程系统14，16，18，20，22，24中导入额外的数据。

例如在CAE系统中通过文件名限定填充状态测量。而在附属的CFC中则显示另一文件名。为了实现类属链接须使这些说明标准化，例如从这些文件名中提取相应的概念。这种标记可能视项目不同而各不相同。但在同一项目内部通常存在统一的协定，从而能够推导出自动机制。此外，设备的文件也是没有关联的。

通过该镜像50首先产生了双重的数据保持。但目前也同样存在双重的数据保持，这是因为目前使用的修改文件正是从工程系统14，16，18，20，22，24中调出的数据。在此的核心是，模型50在高速缓冲存储器的范畴内工作并且不形成独立的、须相应清除的工程数据保持。因此，必须能够基于现有信息推导出跨应用程序的关系。

将工程系统14，16，18，20，22，24的结果数据26，28，30，32，34，36保持在从应用程序中分离的镜像50中的原理意味着，该镜像不需要与应用程序保持持久的连接，界面更多地具有的是松散耦合系统(loosely coupled system)的特征。这也是必要的，因为必须以此为出发点，即不是所有的工程工具都是就地安装且能够在线访问的。当由第三方公司供应配件时，通常不存在访问原始工具的情况，但起动和运行所需的文件和数据都已向其提供。这些信息能够根据相同模式集成在镜像50中(可能其功能范畴是受限的)。

将从应用程序中产生的结果资料(例如PDF文档和CAD图)事后在链接的电子文档的范畴内汇总到一起的方案是已知的。但在这些系统中始终存在这方面存在问题，即将已经产生的文档事后转入这样相互连接的结构中。这一方面会耗费极大的投入，因为例如必须识别和分析文档中的标签(例如必须聚合相关的路径说明)。通过提供相应的输出结构供人使用，工程工具的制造商能够更简单方便地提供数据。这也是本方案的重要方面。

以经过修改的报告的形式进一步传输结果数据的原理是必需的，这是因为多个工程系统14，16，18，20，22，24(特别是CAE系统)不具有真正的数据版本管理功能。但在在认可版本中必须-除了持久的安全措施外-还存在这种可能性，即事后能够识别对于该版本的更改。

产生文档的另一原因在于，只有当客户或第三方企业使用的正好是相同的工具是，才能够将数据传递给该客户或第三方企业，因为对于在设备环境中的数据保持来说，几乎不存在固定的标准。通过文档形式来处理这一问题，特别是资料类型(例如电路图)具有本质上更好的标准化等级。

对于模型50或者说镜像来说，从中产生以下结果：为了将工程数据转化至设备12中，目前仅能使用修改版本作为基础。如果工程系统14，16，18，20，22，24能够进行版本管理，则相应地能够使用工具的标签化状态作为基础。但基于数据保持的有待进行管理的数量结构和所需的灵活性(在项目中须使各不相同的工具相结合)而有意义的是，在此也能够将数据转化为分离的镜像。该修正版本的内容必须保持可分析的特征，该可分析的特征必须跨-应用程序地(至少在结果数据的26，28，30，32，34，36的界面上)协调一致。镜像50必须用作用于红线的数据基础，否则将检测不到设备12上的变化。镜像50必须提供这种可能性，即证明相对于应用程序的发布状态的变化。

特别是后一要求是非常重要的。只有单独的镜像50才能够跨行业地和跨应用程序地提供对工程数据(例如“竣工”状态)的版本管理。通过构建模型50能够为此跨应用程序地统一提供红线功能。借助于来源证明能够将这些变更传输至初始应用程序中。

应用程序的数据必须为数字化镜像50的元模型进行转化。虽然这一步骤仅在释放数据时才进行，但在当数据结构较大时，这有可能导致出现性能问题。对于这种情况来说，合适的应用程序能够支持Delta类属功能，以便仅传递经过更改的部分。镜像50则相反地必须能够处理这种Delta列表。

虽然从工程系统14，16，18，20，22，24中获取的图和设计图必须是可进行分析的(例如对象必须是能够辨认的)，但这些图和设计图却是最终的结果并且不必从复杂的数据保持中进行构建。只有这样才能够高效地管理在设备较大时出现的数量结构(例如在行李输送设备中的13000个电路和功能图)。为了选择图和数据必须持续在大范围的数据保持中进行搜寻的导航装置则几乎是不被接受用于服务和维护目的的。

通过使所有的图和数据以统一的形式存在，能够使这样获得的图和数据与设备的过程数据相互链接。例如此时能够将关于组件的、例如泵的诊断信息直接插入P&ID图中。对于维护技术人员来说，这意味着，他一方面能够继续利用熟悉的资料进行维护工作，但另一方面也能够获得关于设备的最新信息。仅须借助于对象的命名方法建立于SCADA或诊断系统的数据的连接。

对象和文件必须具有来源证明，以便能够授权在初始工具上进行更改。数据和资料始终具有标签，通过该标签能够(在当前项目内部)明确地识别文件和资料。但对于与初始应用程序的连接来说，必须为该信息补充说明，以便能够识别基础的应用程序项目以及应用程序本身。这种来源证明能够记录在当前项目中使用了哪些工具和文件以及在哪里能够找到这些工具和文件。该方案的问题在于数据分类的明确性。在此无法避免的是，数据能够出现在多个工程工具中并且也在能够在那里发生更改。仅这一事实，即在工具中存在多次重复的信息都会导致出现这种情况。但在本发明中由此出发，即规定了由哪个工程工具负责哪些数据。这一责任划分同样也必须在来源证明中体现出来。

图3示出了示教器58的示意图。对于示教器58来说，工程系统14COMOS V9.0被用作用于数字化模型50的平台并且来自CAE系统的项目的数据被转化为镜像50。为此嵌入这样的函数，即在产生修改版本时引起相应导出的函数。该导出本身保持为是可设置的。由于基础系统的结构保持不变，因此，在所考察的情况下，不论CAE系统的对象和关系对于数字化镜像50来说是否具有重要意义，将信息保存其中便已足够。后面的图片还将以管路和仪表图为例对此进行说明。

左边视窗60示出结果数据26的CAE数据A和B是如何映射到镜像50的数据A’和B’上的。一般来说，工程结果所具有的信息不能多于工程本身所具有信息，但存在一系列的简化。例如为了进行工程设计而将不形成标记的结构导入资料中。这些结构同样也不出现在管路和仪表图中，而且也没有映射到数字化镜像中。此外，工程系统14还必须管理包含有待使用组件的、大规模的文档库。而映射5相反则仅具有实际使用的组件。组件本身同样能够简化。例如在上述例子中，当图形符号发生变化时(虽然定语是一致的)，CAE系统必须管理用于容器62的不同模型。CAE系统为此必须管理用于具有平直的、凹陷的的或凸出的底部的容器的主要对象(模型)。这对于镜像50来说是无关紧要的，因为图已被采用并且定语是一致的。原则上来说，镜像完全不需要任何不能在类型主管纲领。在本发明中，本CAE系统正是以这种结构为前提，从而使这无法在示教器58中实施。但这一例子也表明，因此不必在镜像50中使用其中保存了设备制造商的技术文档库信息并且由此也实现了技术保护。唯一所需的附加信息是镜像50的文件的结构。为此，在配置输出线路时-除了说明目标镜像本身外-还须说明作为目的地的结构结点。

在下一步骤中须将通过这种方式采用的数据与其他工程系统的数据相链接。为此必须进行两个步骤。在配置文件中说明在应用程序之间应当形成何种类型的关系(包括对例如1-1，1-n关系等等的说明)并且在第二步骤中说明须在何基础上构建附属主体之间的链接。

通过这种方式，即镜像50中的数据以统一的形式存在，也能提供统一的红线功能。由于此外还进行了来源证明，因此相应目标应用程序上的这种变化是可以转移的。在开头示出的根据图2的浏览器的基础上能够检测定语变化(虽然没有进行语义测试)。变化值能够例如用红色标记。发生了这样的变化的数据和图随后则转换至镜像50中并且从那里出发通过来源证明传递给相应的应有程序。本方法的优点主要在于，通过镜像50并通过版本管理统一地检测这种变化。

图4是在示教器64中实现的、关于如何应用这种系统的例子。从3D图66出发分支导向附属的管路和仪表图68并且从那里出发分支导向控制装置70中的附属的功能编码。从镜像50出发能够通过来源证明(箭头72)启动工程工具并(在这里以CFC的形式)显示附属的结果文件72。此外，还能够由镜像中的功能编码找到附属的存储器装置74以及CPU并通过其订单号直接打开服务和维护客户端。

过去曾多次尝试构建所谓的通用信息模型(Common Information Modelle)，通用信息模型应提供对工程数据进行统一访问的可能性。当前模型通过以下特征与传统方案相区分：

1.不必人工启动单独的输出管道，以便从工程系统14，16，18，20，22，24产生这种模型50。模型的构建隐性地在工程设计中的批准方法中实现。

2.不使用工程数据的复杂抽取结果，而是仅采用结果数据26，28，30，32，34，36。数据的采用结构化地与工程设计中的批准方法以及创建设备12的文件相应地进行。与项目所取得的进展相应地逐步构建模型50。

3.工程系统14，16，18，20，22，24的结果数据26，28，30，32，34，36的链接类属化地进行。可以为项目限定规则，这些规则通过标记使数据相互连接。

4.模型50使用基础性的工程系统14，16，18，20，22，24所具有的结构，例如CAE工具的设备结构和来自自动化工具中的技术(功能)等级。虽然存在共同的元模型，但该元模型仅用于使统一地访问数据和关系成为可能。这是核心原理，因为只有这样才能够通过来源证明管理对于基础工具的关联并由此能够就地在设备12上以简单的方式和方法将变化纳入工具中。

5.与应用程序本身的数据保持相比，结果数据26，28，30，32，34，36、例如R&I图或电路图具有相对较高的标准化等级。如果在批准方法中仅使用这些报告中的数据，那么，即使源应用程序是以基础的结构组件为基础的，由此也同样会达到一定的标准化等级。通过进行这样的处理，即将这些经过修改的、包含附属数据的文件作为基础，系统也能够整合外部应用程序的数据，其前提是，系统允许将经过修改的文件相应地导出。这是这种处理方式的非常重要的一个方面。

6.通过来源证明能够将镜像50的数据与工程系统14，16，18，20，22，24进行比较并由此保持其时效性和一致性。

7.镜像50不是工程系统14，16，18，20，22，24的镜像，而是被优化用于对设备12进行运行管理。该镜像使得设备文件能够与过程数据相连接并加设诊断程序(例如能够遍历数据，以便通过已连接的客户和生产商的报告识别泄漏处并在位置上加以限定)。

8.这种处理方式的一个非常重要的方面在于，这种集成方式能够低风险地且逐步进行。仅考察在关于工程工具的数据保持方面体现抽象层的工程结果(例如隐性地通过报告或输入结构实现)。不必改变工具的内部数据保持，仅使用对该数据保持的“观点”。然而必须使这些结果彼此间协调一致。但这可以通过这种方式分步进行，即逐步增添工具结果。在应将工程工具设计为具有普遍性时，这种一致性是一个基本前提。

9.镜像的产生同时也是一种在结果数据的相互作用方面的质量控制。工程应用程序仅能够使通过它们本身进行管理的数据保持一致。而缺失的跨应用程序的相互关系则是无法识别的。但在构建镜像时会报告这一点。

10.如果建立了这种模型并且其具有例如版本管理或跨行业的选择等特征，则工程工具将会-虽然它们会始终保持独立发展-相互结合。基于市场压力这也是隐形地进行的。

参考标号表

10 装置

12 设备

14，16，18 工程系统

20，22，24 工程系统

26，28，30 结果数据

32，34，36 工程系统

40 接收装置

42 计算装置

44 组件

46，48 界面

50 模型

52，54，56 视窗

58，60 视窗

62 容器

64 示教器

66 图

68 仪表图

70 控制装置

72 结果文件

74 存储器装置

76 服务和为维护客户端

A，A’ 数据

B，B’ 数据