CN101763043B - 用于自动化协同框架的方法和系统 - Google Patents

Abstract

提供一种自动化协同框架(ACF)。该ACF包括定义通用数据管理方案的抽象自动化模型(AAM)。该AAM被扩展使得根据从用户接收的控制解决方案来定义扩展数据管理方案。然后具体自动化模型(CAM)实现具体数据管理方案，其中该具体数据管理方案根据通用数据管理方案和扩展数据管理方案得出。

Description

用于自动化协同框架的方法和系统

技术领域

所要保护的主题内容一般地涉及工业控制系统，且更具体地，涉及一种用于在抽象设定中设计控制解决方案的开发平台。

背景技术

工业控制环境一般地可涉及执行各种自动机械和/或电子功能的复杂的机械电子机构、电子机械机构和/或机器人机构。这样的机构可包括可以提供具体的物理输出的工业电机、泵、传输装置、升降机、钻机、制冷系统等。典型地，工业环境利用一个或更多个设备来确定何时激活或停止这样的机构，以及确定合适的激活水平(例如，供给可变输入电机的电流的量)。另外，控制设备与可以确定合适的时间、程度、方式等的逻辑程序代码相关，以便根据各个可确定的环境(例如，其它设备的输出、光学传感器的读数、电子测量如在设备中的电流水平、设备旋转的次数或运动等)来操作这样的机构。

现代控制应用变得越来越复杂。存在许多可用的开发程序来设计应用软件，所述应用软件又必需创建被各种不同的硬件平台支持的可执行代码。一般来说，开发者希望能够以及时的方式向他们的最终用户提供新的特征。如果这样的开发涉及从开发程序中提供的标准提供内容的任意类型的定制，开发者可能需要向开发程序的OEM提供者请求变化。这种请求可能涉及显著的成本和威胁市场的耗时。因而，需要一种开发平台，其使开发者能够在可以有效地促进代码布置和可以有效地促进在不同类型的最终硬件平台上的执行的设定中设计控制方案。

发明内容

以下概述呈现的是简要概括，以提供对这里描述的某些方面的基本理解。该概述不是宽泛性的概括，也不旨在标识关键元件或者表述这里描述的方面的范围。该概述的唯一目的在于，以简要方式呈现一些特征，作为后面呈现的更具体描述的前言。

提供一种开发平台，其采用通用编程模型来在抽象设定中设计控制解决方案，同时促进在多个最终硬件平台上的代码部署和执行。该开发平台生成抽象自动化模型(AbstractAutomationModel，AAM)，该抽象自动化模型定义数据管理方案以便管理通常定义的数据对象。作为大型框架或开发环境的一部分，具体自动化模型(ConcreteAutomationModel，CAM)根据不同开发环境的指定项目格式，提供与AAM的通用数据对象相关联的数据接口。例如，开发程序的各种版本可以具有关联的CAM，其将相应的版本链接或映射到AAM的下层抽象。在另一个例子中，具体硬件供应商可以针对该供应商唯一具有的具体类型的编程接口提供CAM。通过提供AAM的抽象并且经由CAM映射成不同程序环境的任意具体的细微差别，开发者可以根据AAM提供的通用编程模型来迅速地添加新特征，从而有效地支持任意可以获得的开发程序和有效地支持转换为基本上任意可以获得的开发程序。

为了实现上述以及相关目的，在具体的示例性例子中详细给出下面的描述和附图。这些例子示出其中采用这里描述的原理的各种方式中的一些方式。当结合附图考虑时从以下具体描述中显然可以得到其它优点和新颖特征。

附图说明

图1是用于对控制解决方案进行编程的优选的自动化协同框架的高级示意图。

图2是示出经由多个CAM而与多个项目格式接口连接的AAM的示意图。

图3是示出程序组织单元块的通用分类的示意图。

图4是示出通用程序组织单元块的示意图。

图5是示出通用完整性树的示意图。

图6是示出用于生成项目格式接口的方法的流程图；

图7是示出相应于项目的名称空间的示例性生成的框图。

图8是示出经由具体自动化模型而与具体项目格式接口连接的扩展抽象自动化模型的示意图。

图9是用于可在自动化协同框架上操作的平台的示例性设计外壳的高级示意图。

图10是示出用于可在自动化协同框架上操作的平台的示例性架构的框图。

图11是用于可在自动化协同框架上操作的平台的示例性核心系统的高级示意图。

图12是用于支持可在自动化协同框架上操作的平台上的系统权限的示例性架构方案的高级示意图。

图13是如何将抽象模型整合到可在自动化协同框架上操作的平台的框架中的示例性图示。

图14是示出由自动化协同框架支持的多语言编辑器的示例性操作的框图。

图15是可在自动化协同框架上操作的示例性汇编模型的高级示意图。

图16是表示其中可以实现这里描述的各种方面的示例性非限制的联网环境的框图。

图17是表示其中可以实现这里描述的各种方面的一个或更多个例子的示例性非限制的计算系统或操作环境的框图。

具体实施方式

公开了用于提供自动化协同框架(AutomationCollaborativeframework，ACF)的方法和系统。在一方面，生成AAM使得AAM定义抽象数据管理方案。然后，AAM被扩展，使得根据从用户接收的控制解决方案来定义扩展数据管理方案。然后，CAM实现具体数据管理方案，其中根据抽象数据管理方案和扩展数据管理方案来得到具体数据管理方案。

首先参见图1，提供了优选ACF的高级示意图。如所示，ACF100包括CAM生成器110和AAM生成器120。

在一方面，AAM生成器120生成AAM，该AAM允许控制软件设计是在所利用的开发软件的类型或具体版本之外透明地进行。AAM是ACF中描述如何表示和访问数据的部分。而且，AAM定义控制结构，该控制结构表示具有配置、资源、程序等的属性的通用或抽象数据对象。AAM还定义了确保结构(如树结构)完整性的完整性规则以及用来更新或查询数据的操作。

如所示，由AAM生成器120生成的AAM可以被配置成接收以多个项目格式160中的任意格式开发的程序命令。在这种配置中，每个项目格式160通过相关的CAM与生成的AAM进行接口连接。这里，应理解每个项目格式160可以表示具体的开发程序(例如，ISaGRAF、RSLogix、SAMA等)以及具体的编程版本(例如，ISaGRAFv.1、ISaGRAFv.1、ISaGRAFv.1等)。

AAM还被配置成接收插件开发支持以便增加AAM的功能性。这种配置可以包括允许AAM从各种插件提供者(包括内部开发者和/或第三方开发者)接收多个插件130中的任意一个。内部开发者例如可以提供对应于它们具体的项目格式160的插件(例如，ISaGRAF插件，其可以包括编译器和IEC标准插件)，而第三方开发者可以简单地提供无需与具体格式160对应的通用插件(例如，配置插件、编译器插件、报警插件、运动插件等)。

在另一方面，AAM还可以被配置成支持多个现有应用140(针对已知的工业解决方案而设计或被预封装)中任意一个。这样的现有应用140例如可以包括分离解决方案、运动控制解决方案、SCADA解决方案、处理解决方案、机器人解决方案和功能安全管理解决方案。

应注意，AAM的目的在于统一单个通用标准周围的自动化项目格式。这样，AAM可基于提升互操作性的标准，例如通过在项目格式160之间允许数据共享和再使用。在一方面，AAM从公共的基础模型解决方案或标准(例如IEC61131和61499)中得出。可以针对下层模型采用任意的编程标准，IEC61131和61499支持当今世界上的大部分的已知自动化语言。

为了生成具体的AAM，AAM生成器120可以开始于通用根AAM。这种根AAM例如可以包括程序组织单元(ProgramOrganizationUnit，POU)的通用表述。POU是通常已知的从其中建立程序和项目的块。具体的PLC项目可以包括：由PLC制作者装上或是由用户创建的POU。用户程序可以用来建立可以在新的项目中再次使用的测试POU的库。IEC61131-3通过约定具体POU块必须尽可能地保持“通用”即独立于硬件来支持这一方面的软件的再使用。

通过提供POU的通用表示，限制了块类型的变化以及其往往不清楚的含义，这样简化了POU的使用。在图2中，提供了示出POU块的通用表示的示意性视图。作为具体例子，通用表示反映了IEC61131-3标准(其将不同的PLC制作者的块类型减少成三个统一的基本类型)。如所示，常规PLC块类型200(其可以包括功能块201、顺序块202、组织块203、程序块204和数据块205)被转换成通用块类型210(其可以包括功能块214、程序块212和功能216)。这里，应注意为了与IEC61131标准一致，数据块205也还可以被功能块存储器/实例或全局多元变量代替。

在一方面，功能块214可以被分配参数，且可以具有静态变量(即可以具有存储器)。在利用同一输入参数调用时，功能块214(例如，计数器或定时器块)将产生依赖于内部变量(VAR)和外部变量(VAR_EXTERNAL)的状态的值，该值优选地从功能块214的一个执行被保留到下一执行。

然后，对程序块212建模以表示主程序。可以在POU中或在其以上(例如在资源、配置)声明分配给物理地址的所有变量(例如，PLC输入和输出)。在所有其它方面，可以对程序块212建模以操作类似的功能块214。

关于函数216，这些块也可被分配参数，但是不同于功能块214，函数216可以不具有静态变量(即不具有存储器)。因此，在利用同一输入参数调用时，函数216生成与其函数值(即其输出)相同的结果。此外，函数216具有输入参数和作为返回值的函数值，而功能块212和功能块214可以具有输入和输出参数。

应注意，对于这些具体例子，将POU建模为封装单元(其可以独立于其它程序部件被编译)。编译的POU以后可以链接在一起，以便创建完整程序。然而，在这种模型中应采用完整性规则集。例如，为了使POU名称在整个项目中已知，这些规则可以要求名称(一旦被使用)。以一些其它(高级)语言的局部子程序可能是不允许的。在对POU(声明)进行编程后，其名称和调用接口对项目中的其它POU是全局已知的。由此，POU的独立性促进了自动化任务的广泛模型化以及已实现的软件单元和测试软件单元的再使用。

在图3中，提供示出通用POU块的方面的示意图。如所示，通用POU400可以包括所示出的头部410、声明420、代码430、脚注440。

在一方面中，头部410标识POU的开始，而脚注440标识POU的结束。头部410可以包括关于POU类型和名称的信息。这样的信息例如可以将POU识别为名为MY_PROGRAM(我的程序)的程序块312。如果POU是函数316，头部410可以进一步包括数据类型信息。

在另一方面中，在POU400中使用的所有变量被定义在声明420中。在这一方面中，声明可以以图形或文本的形式编程。在从POU400外部可见的变量(即，POU接口变量)和POU400的本地变量之间进行区分。此外，在POU中使用的本地数据区域以及POU接口优选地通过在声明420中将POU变量分配给变量类型而定义。POU接口例如可以包括调用/启用接口(形式参数)、返回值(输出参数或函数返回值)以及全局接口(具有全局/外部变量和访问路径)。在一些方面，可以允许返回值和调用接口的图形表示，以便适应诸如梯形图(LadderDiagram，LD)和功能块图(FunctionBlockDiagram，FBD)的语言。

然后，POU的主体可以提供在紧跟着声明420的代码430中。代码430包括可以以图形或文本形式提供的由PLC执行的指令。所述指令可以例如包括：以多个编程语言中的任意编程语言编程的逻辑电路或算法，这些编程语言诸如LD、FBD、顺序功能流程图(SequentialFunctionChart，SFC)、指令列表(InstructionLIST，IL)和结构文本(StructuredText，ST)。

从用户获得的数据对象(诸如POU)可以根据通用完整性规则集来组织。在图4中，提供了示出根据示意性的完整性规则集的通用根AAM树。如前所述，AAM可以从公共的基础模型方案或标准(诸如IEC61131和61499)得出。作为一个具体例子，根AAM树500从IEC61131得出。如所示，根AAM树500的层次可以被组织为一组目录和子目录。用于具体项目的数据对象例如可以存储到多个目录中的任意一个中，所述多个目录包括数据类型目录、资源类型目录、程序类型目录、功能块目录、函数目录或配置目录。然后每个目录可以被进一步地分成一组子目录，子目录本身可以被分成进一步的子目录。

接着参考图5，提供了示出CAM的示意性功能的图。作为具体例子，如所示，AAM200经由多个CAM210与多个项目格式220接口连接。在这一例子中，每个CAM210对应于具体的项目格式220，并且是AAM200的具体实例。具体而言，每个CAM210根据与该CAM210有关的具体项目格式220来扩展根AAM，并相应地实现合适的数据结构、完整性规则和更新/请求操作。而且，每个CAM210定义了抽象接口来扩展与相应于CAM的数据相对应的AAM，并且还定义了用于实现相应于CAM的接口的具体类。然后，通过每个CAM210来具体地实现在AAM200中定义的接口，以根据具体项目格式220的结构来管理数据。

在图6中，提供了用于生成具体项目格式接口的方法的示意性流程图。如所示，处理在定义根AAM的步骤600处开始。如前所述，这样的根AAM可以包括用于数据结构、完整性规则和更新/查询操作的多个通用定义。

在步骤610，处理继续进行根AAM的扩展。具体而言，根AAM被扩展成包括未被根AAM定义的用于其它数据结构、完整性规则和操作的相应于项目的定义。这里，应注意，这种扩展可以是横向的或纵向的。横向扩展例如可以包括将AAM扩展成整合工业应用(诸如结合图1中的现有应用140讨论的程序)，而纵向扩展整合具体的项目格式。

在步骤620，在CAM实现用于具体项目格式的合适AAM的情况下，处理结束。这里，应理解，每个CAM可以利用扩展AAM元件的一些或全部。为了提升互操作性，每个CAM可以被配置成实现与根AAM最相似的AAM。

在图7中，提供了示出相应于项目的名称空间的示意性生成的框图。作为具体例子，处理在根名称空间710(其中数据根据一组通用类进行了分类)处开始。如所示，这样的根名称空间710例如可以简单地将数据分类为声明数据、命令式数据或图形数据。然后，根名称空间710可以发展成变为名称空间720，这将根名称空间710扩展成包括未被根名称空间710定义的相应于具体项目格式的类。进一步，名称空间730优选地只包括实际上使用的扩展名称空间720定义的类。

在图8中，提供了经由CAM与具体的项目格式接口连接的AAM的示意性示图。这里，根AAM800被示出为被扩展成AAM802，以便反映任意可能的横向/纵向扩展。如所示，CAM810提供具有接口的AAM802，该接口允许访问对应于具体项目格式的数据和文件。CAM810例如可以提供接口，以便经由合适的活动X数据对象(ActiveXdataobject，ADO)配置812来访问项目数据820。CAM810还可以提供接口，以便经由分析程序/生成器814来访问相应于项目的文本文件822(例如，POU主体文本文件)和经由分析程序/生成器816来访问相应于项目的图形布局文件824。

应理解，通过设计具体的开发平台可以暴露ACF的特征和下层控制模型。这样的平台可以为用户提供熟悉的软件设计环境，以便创建特征和功能。事实上，由于许多控制软件开发平台存在为单独的实体且在这样的平台可以应用之前可能需要许多年的开发和测试，所以这样的平台通常是以不灵活的方式(其中直到新平台被设计成支持较新版本的软件范例和模型，才可以支持所述较新版本的软件范例和模型)进行设计的。

在图9中，提供了用于可在ACF上操作的平台的示意性设计外壳的高级示意图。这里，应理解设计外壳900可以适应于许多技术，以便支持用于控制和工业自动化平台的快速软件开发。如所示，外壳900可以包括中心面板910、左面板920、右面板930和底面板940，每个面板分别可以包括多个功能/视窗特征。这些特征例如可以包括用于控制解决方案的其它模板、版本控制组件、模型编辑器、项目控制特征、历史控制特征、库、属性和调试选项。还可以提供各种装置和输入/输出视窗(其可以促进从下层原代码到机器实现的软件的完全可视化)。应理解，尽管可以通过可以得到的视窗(Windows)技术来开发外壳900，但外壳900也可以类似地通过UNIX、Java、Linux等来构建。而且，外壳900优选地提供根据控制系统设计者的具体要求被剪裁的接口平台。

在图10中，提供了示出可以在ACF上操作的平台的示例性架构的框图。如所示，这样的架构的配置优选地允许平台1000先识别核心名称空间1010和公共名称空间1020。核心名称空间1010优选地将与系统有关的可以再用的组件(诸如系统记录器、权限管理器和外壳)进行分组，而公共名称空间1020优选地将可以再用的数据、服务和视图进行了组合。如所示，还可以支持多项目格式1303和插件1040，以及可视化工作室编辑器1050的概括，以便提供公共视图和项目格式文件的更容易的相互连接。

接着参考图11，提供了示意性的核心日志系统的高级示意图。如所示，这样的系统1100可以包括所示的日志组件1110、外壳组件1120和权限组件1130。在一个方面，日志组件1110提供用于记录可以影响下层软件系统的事件的能力。日志组件1110例如可以设置成，使得日志声明保持为加载代码(shippedcode)而没有引起高的执行成本。日志过滤器可以被配置成，避免根据诸如映射诊断上下文(MappedDiagnosticContexts，MDC)、嵌套诊断上下文(NestedDiagnosticContext)、错误水平匹配等的标准来避免记录事件。也可以创建新的过滤器类型以允许更任意的过滤。日志框架优选地将日志事件写入到多个输出，诸如数据库、使用.NET远程的远程接收器、网页服务、文本文件(具有或不具有复用)等。然后可以创建新的目标类型以便再次将事件导引到一些其它的输出。日志框架还优选地支持分级记录。

接着参考图12，提供用于支持系统权限的方案的高级示图。在这种方案1200中，许可管理器1210优选地使得设计者能够在给定的控制解决方案中控制智能化的属性访问(例如，代码模块访问)。在一个方面中，许可管理器1210可以包括许可编辑器，以便显示特征允许和限制。还优选地提供角色管理器1220，以便允许开发者基于最终用户在组织内的角色(例如，管理者、技术人员)控制对模型特征的访问。在这一方面，可以提供角色编辑器以针对部署的控制解决方案的各个软件特征来定义角色。

如所示，特征矩阵1230还可以耦合到许可管理器1210和角色管理器1220。在一个方面中，特征矩阵1230用作动态地使能/禁止、示出/隐藏、选中/未选中各种特征的决策表。特征矩阵1230优选地映射根访问允许对象上的所有特征，其中特征结构可以扩展允许对象。这种扩展例如可以添加任意的以下三种命令状态标记的组合：使能/禁止、可见/隐藏和选中/未选中。

在另一方面，特征矩阵1230针对被加载的模块1240、1242和1244声明的每个特征创建允许集。在初始特征声明中，例如特征矩阵1230从许可提供者处检索特征状态。然后，允许集聚集许可、用户角色或元件状态许可对象。在一些方面，任意的模块、项目格式或插件可以将其它许可对象注册到这一集合中。任意未知的特征名称可被视作是“自定义”的，其中特征矩阵1230假设它们被使能。在这种情况下，许可有效是通过这种扩展控制的，由此通过标准命令更新处理程序和许可的方法来使用这种允许集。然后，许可的方法调用这种允许的“要求”方法(其在命令装置不是“使能”时，提出安全性要求)。

应注意到，还可以包括现场总线组件(未示出)以便利用控制系统目标平台来提供公共API来管理对话、下载、上载和在线变化。如果包括API，则API设计是可扩展的，以便支持任意的自动化协议。

图13是示出如何将抽象模型整合到可在自动化协同框架上操作的平台中的示意性示图。在这样的方案1300中，抽象模型1310优选地获得自动化域的公用数据结构。抽象模型1310例如可以是组编程接口，其中每个接口反映可以暴露在自动化项目的数据中的可能方面。作为一个具体例子，服务1330是处理单元(使用或改变被抽象模型暴露的数据)，而视图1320是用于将数据呈现给用户的用户接口控制。然后，使用数据抽象接口或间接地通过服务1330来使用或改变抽象模型暴露的数据。

应注意，因为期望用于现代控制系统的开发程序包可以(以及有时候)以不同的控制系统语言来操作，当构建了大量的应用时，将语言混合在给定的平台内可能是成问题的。在一个方面，ACF可以实现允许创建自定义形状的多语言编辑器，所述自定义形状在控制系统解决方案内定义了新的控制功能或关系。在图14中，提供示出这种多语言编辑器的示意性操作的框图。如所示，编辑器1400可以与控制面板1410结合使用，以便产生具体的多语言文件1420。编辑器1400例如可以是型板编辑器，其允许用户定义他们自己的形状以便创建下层控制解决方案。这样的型板编辑器可以被配置成使自定义形状操作为宏函数(作为被选来定义具体控制解决方案的其它函数的集合)。因此，在一个方面，面板1410可以用来改变显示类型(例如，视窗风格：细节、具有工具提示的图标...)、支持拖拽操作、提供可缩放的窗格和分类图标(其中每个型板可以具有其自己的容器形状)。面板1410还可以用来基于库硬件(XML)来输入新的型板和允许OEM利用它们自己的形状来创建它们自己的型板。

应进一步注意，一些软件开发程序将高级的控制语言(如LD和SFC)向下编译成目标系统操作指令。通常，编译是对已经被转换成PLC目标代码(诸如已经被编译成C+可执行格式的C+源代码)较高级的源代码的编译。这种编译方案的问题在于支持多于一种类型的高级语言编译对许多系统来说是不灵活的。执行性能也是问题，因为在目标水平的编译通常不是有效的，并且远离实际的目标硬件语言(作为最高的可能执行格式的形式)。

这里描述的ACF提供了克服这些限制的用于开发编译模型的框架。具体而言，ACF提供了用于创建编译模型的框架，其减少了需要用来实现较高级的控制解决方案的代码量，增加了代码的执行性能。

在图15中，提供了可在ACF上执行的示意性编译模型的高级示意图。在这样的模型1700中，可以采用支持各种语言的多个编辑器1710(例如，LD编辑器、SFC编辑器、FBD编辑器等)中的任意一个。然后，来自每个编辑器1710的输出分别被编译器1720编译成中间语言(IntermediateLanguage，IL)语言并被存储为IL文件1730。然后，IL汇编程序1740处理这些文件并将它们存储在IL语言数据库1750中。然后，IL语言数据库1750的内容经由连接器1760连接成被大多数目标微处理器支持的二进制格式的高性能指令1770。然后，耦合至二进制数据库1770、PLC定义数据库1782和目标可执行代码数据库1790的导引程序1780将这种二进制代码转换成合适的目标可执行代码。具体地，数据库1782利用定义期望的最终用户硬件环境的具体的PLC定义来提供导引程序1780。然后，导引程序1780考虑到在PLC定义中描述的实际PLC硬件限制，将二进制源代码转换成合适的目标可执行代码。

应注意，在本申请中所使用的术语(诸如“组件”、“模块”、“批处理”等)指的是：涉及计算机的实体、任意硬件、硬件和软件的组合、软件或者在施加到用于工业控制的自动化系统时执行的软件。例如，组件可以是但是不限于是，在处理器上运行的处理、处理器、对象、可执行的执行线程、程序和计算机。通过图示可以看出，在服务器上允许的应用和服务都可以是组件。一个或更多个组件可以驻留处理器或执行线程内，且组件可以被局域化在一个计算机上或可以分布在两个或更多个计算机、工业控制器或与其通信的模块之间。

本领域普通技术人员可以理解到，这里描述的ACF的各个方面可以结合任何计算机或者其它客户端或服务器设备来实现，这些计算机或者其它客户端或服务器设备可以被部署为计算机网络的一部分或者分布式计算环境中，并且可以连接到任何种类的数据库。在这点上，这里描述的各个方面可以在任何计算机系统或环境(具有任何数目的存储器或存储单元以及在任何数目的存储单元之中发生的任何数目的应用和处理)中实现。这包括但不限于具有部署在网络环境或分布式计算环境中的、具有远程或本地存储装置的服务器计算机和客户端计算机的环境。

分布式计算提供计算设备和系统之间通过通信交换的计算机资源和服务的共享。这些资源和服务包括信息、针对对象(诸如文件)的高速缓存存储和磁盘存储的交换。这些资源和服务还包括用于负载平衡、资源的扩展、处理的专业化等的多个处理单元之间的处理能力的共享。分布式计算利用网络连接性的优点，使得客户端平衡它们的集合力量以利于整个企业。在这点上，各种设备可以具有可以协作来执行主题公开内容的各个方面中任意方面的一个或更多个方面的应用、对象或资源。

图16提供示例性联网计算环境或分布式计算环境的示意图。分布式计算环境包括计算对象1610、1620等以及计算对象或设备1620、1622、1624、1626、1628等，这些计算对象或设备可以包括如应用1630、1632、1634、1636、1638表示的程序、方法、数据存储、可编程逻辑等。可以理解到，对象1610、1612等和计算对象或设备1620、1622、1624、1626、1628等可以包括不同的设备，诸如PDA、音频/视频设备、移动电话、MP3播放器、个人计算机、膝上型电脑等。

每个对象1610、1612等和计算对象或设备1620、1622、1624、1626、1628等可以通过通信网络1640直接或间接地与一个或更多个其它对象1610、1612等和计算对象或设备1620、1622、1624、1626、1628等进行通信。尽管在图16中作为单个元件示出，但网络1640可以包括向图16的系统提供服务的其它计算对象和计算设备，并且/或者可以表示没有示出的多个互连网络。每个对象1610、1612等或1620、1622、1624、1626、1628等也可以包含应用(诸如应用1630、1632、1634、1636、1638)，其可以利用适于与基于列的编码和询问处理进行通信、对基于列的编码和询问处理进行处理或对基于列的编码和询问处理进行实现的API或其它对象、软件、固件和/或硬件，该基于列的编码和询问处理是根据主题公开内容的各个方面提供的。

存在支持分布式计算环境的各种系统、组件和网络配置。例如，计算系统可以通过有线或无线系统、通过本地网络或宽广分布的网络连接在一起。当前，许多网络连接到因特网，因特网提供用于宽广分布式计算的基础设施并涵盖许多不同的网络，但是仍可以使用任何网络基础设施进行与如各个方面中所述的基于列的编码和询问处理有关的示例性通信。

因此，可以利用大量网络拓扑和网络基础设施(诸如客户端/服务器、点对点或混合架构)。“客户端”是使用与其不相关的另一类或组的服务的一类或组的成员。客户端可以为请求另一程序或处理所提供的服务的一个处理，即，大致一组指令或任务。客户端处理利用所请求的服务，而无需“知道”关于另一程序或服务本身的任何工作细节。

在客户端/服务器架构特别是联网系统中，客户端通常为访问另一计算机(例如服务器)所提供的共享网络资源的计算机。尽管根据情况，任何计算机都可以被看作是客户端、服务器或兼为二者，但在图16的图示中，作为非限制性例子，可以将计算机1620、1622、1624、1626、1628等看作是客户端，并且可以将计算机1610、1612等看作是服务器，其中服务器1610、1612等提供数据服务，诸如从客户端计算机1620、1622、1624、1626、1628等接收数据、数据的存储、数据的处理、将数据传送到客户端计算机1620、1622、1624、1626、1628等。这些计算装置中的任何计算装置可以为处理数据、编码数据、询问数据或请求服务或任务(其涉及如这里针对一个或更多个方面描述的基于列的变化和询问处理)。

服务器通常为可通过远程或本地网络(诸如因特网或无线网络基础设施)访问的远程计算机系统。客户端处理可以在第一计算机系统中是激活的，服务器处理可以在第二计算机系统中是激活的，第一计算机系统和第二计算机系统彼此通过通信介质通信，因而提供分布式功能并且允许多个客户端利用服务器的信息聚集能力。按照基于列的编码和询问处理利用的任何软件对象可以独立提供，或者分布在多个计算设备或对象之中。

在其中通信网络/总线1640为因特网的网络环境中，例如，服务器1610、1612等可以为Web服务器，客户端1620、1622、1624、1626、1628等经由的大量已知协议中的任何协议(诸如超文本传输协议(HypertextTransferProtocol，HTTP))与该Web服务器进行通信。作为分布式计算环境的特性，服务器1610、1612等也可以用作客户端1620、1622、1624、1626、1628等。

有利地，如所提到的，这里描述的技术可以应用于其中期望快速询问大量数据的任何设备。因此，应理解到，可以针对与本发明各个方面有关的用途(即设备可能希望扫描或处理大量数据以便获得快速有效的结果的任何场合)来设想手持、便携和其它所有种类的计算设备和计算对象。因此，下面在图17中描述的通用远程计算机只是计算设备的一个例子。

尽管不要求，但这些方面可以经由供设备或对象的服务的开发者使用的操作系统来部分地实现，和/或包括在进行操作以执行这里描述的各个方面的一个或更多个功能方面的应用软件内。软件可以在计算机可执行指令的通用上下文(诸如程序模块)中描述，该计算机可执行指令通过一个或更多个计算机(诸如客户端工作站、服务器或其它设备)执行。本领域技术人员将理解到，计算机系统具有可以用来传送数据的各种配置和协议，并且因此不应限于任何具体的配置或协议。

因而，图17示出其中可以实现这里描述的一个或更多个方面的合适的计算系统环境1700的例子，但如上面所澄清的那样，计算系统环境1700仅是合适的计算环境的一个例子并且不旨在于暗示关于功能或使用范围的任何限制。计算环境1700既不能解释为关于在示例性操作环境1700中示出的组件的任何一个或它们的组合具有任何依赖性或要求。

参照图17，用于实现一个或更多个方面的示例性远程设备包括以计算机1710形式的通用计算设备。计算机1710的组件可以包括但不限于处理单元1720、系统存储器1730和系统总线1722，该系统总线1722将包括系统存储器的各种系统组件耦合到处理单元1720。

计算机1710典型地包括各种计算机可读介质，并且可以为可通过计算机1710访问的任何可以获得的介质。系统存储器1730可以包括易失性和/或非易失性存储器(诸如只读存储器(ROM)和/或随机访问存储器(RAM))形式的计算机存储介质。作为例子，并且不作为限制，存储器1730也可以包括操作系统、应用程序、其它程序模块以及程序数据。

用户可以通过输入设备1740将命令和信息输入到计算机1710中。显示器或其它类型的显示设备也经由接口诸如输出接口1750连接到系统总线1722。除了显示器之外，计算机还可以包括可通过输出接口1750连接的其它外围输入设备，诸如扬声器和打印机。

计算机1710可以使用与一个或更多个其它远程计算机(诸如远程计算机1770)的逻辑连接在联网或分布式环境中操作。远程计算机1770可以为个人计算机、服务器、路由器、网络PC、对等设备或其它公用网络节点，或者任何其它远程介质消耗或传输设备，并且可以包括上面关于计算机1710描述的元件中的任何元件或者所有元件。图17所示的逻辑连接包括网络1772(诸如局域网(LAN)或广域网(WAN))，但也可以包括其它网络/总线。这样的联网环境在家庭、办公室、企业范围的计算机网络、内联网和因特网中是常见的。

如上所述，尽管关于各种计算设备和网络架构描述了示例性方面，但可以将下层概念应用于其中期望压缩大规模数据或处理对大规模数据的询问的任何网络系统和任何计算设备或系统。

而且，存在多种方式实现相同或相似的功能，例如适当的API、工具箱、驱动代码、操作系统、控制、独立或可下载软件对象等，使得应用和服务使用有效的编码和询问技术。因而，从API(或其它软件对象)以及从提供基于列的编码和/或询问处理的软件或硬件对象的角度，可以预期这里公开的方面。因此，这里描述的各种实施例可以具有整体为硬件、部分为硬件和部分为软件以及整体为软件的各个方面。

上述主题包括各种示例性方面。然而，应理解到，不可能描述用于描述这些方面的每一个可预想的组件或方法。本领域普通技术人员可以认识到，进一步组合或置换是可能的。可以采用各种方法或架构来实现本发明的主题、修改、变型或其等同方案。因此，这里描述的方面的所有这样的实现旨在于包含权利要求的范围和精神。此外，就在说明书或权利要求中使用术语“包括”而言，这种术语“包括”旨在于是开放式的，类似于术语“包括”在权利要求中用作过渡词时所被解释的方式。

根据本发明的一方面，提供一种用于提供自动化协同框架的方法，包括：生成抽象自动化模型，其中所述抽象自动化模型定义抽象数据管理方案；扩展所述抽象自动化模型，使得定义扩展数据管理方案，其中扩展步骤是根据从用户接收的控制解决方案；以及实现具体数据管理方案，其中所述具体数据管理方案根据所述抽象数据管理方案和所述扩展数据管理方案得出。

根据上述方案，进一步包括定义所述扩展数据管理方案以符合至少一个项目格式。

根据上述方案，进一步包括定义所述扩展数据管理方案以符合至少一个现有应用。

根据上述方案，进一步包括利用至少一个插件来支持所述自动化协同框架。

根据上述方案，进一步包括定义所述抽象数据管理方案以符合IEC-61131标准或者扩展IEC-61131标准。

根据上述方案，进一步包括定义所述抽象数据管理方案以符合IEC-61499标准或者扩展IEC-61499标准。

根据上述方案，其中所述抽象自动化模型包括多个数据对象，并且其中所述抽象自动化模型为所述数据对象定义数据结构。

根据上述方案，其中所述抽象自动化模型包括多个数据对象，并且其中所述抽象自动化模型为所述数据对象、服务和用户接口定义完整性规则集。

根据上述方案，其中所述抽象自动化模型包括多个数据对象，并且其中所述抽象自动化模型定义用于询问和更新所述数据对象、服务和用户接口的一组操作。

根据上述方案，进一步包括促进至少一个代码执行。

根据本发明的第二方面，提供一种用于提供自动化协同框架的在一个或更多个处理器上执行的系统，包括：抽象自动化模型，其中所述抽象自动化模型提供根抽象自动化模型，所述根抽象自动化模型定义抽象数据管理方案，并且其中所述抽象自动化模型提供扩展抽象自动化模型，所述扩展抽象自动化模型根据从用户接收的控制解决方案来定义扩展数据管理方案；以及具体自动化模型，其中所述具体自动化模型实现具体数据管理方案，所述具体数据管理方案根据所述抽象数据管理方案和所述扩展数据管理方案得出。

根据第二方面的方案，其中所述扩展数据管理方案符合至少一个项目格式。

根据第二方面的方案，其中所述扩展数据管理方案符合至少一个现有应用。

根据第二方面的方案，其中所述至少一个项目格式中的每一个包括多个数据对象，并且其中多个抽象自动化模型层中的每一个为所述数据对象定义数据结构。

根据第二方面的方案，其中所述至少一个项目格式中的每一个包括多个数据对象，并且其中多个抽象自动化模型层中的每一个为所述数据对象定义完整性规则集。

根据第二方面的方案，其中所述至少一个项目格式中的每一个包括多个数据对象，并且其中多个抽象自动化模型层中的每一个定义用于询问和更新所述数据对象的一组操作。

根据本发明的第三方面，提供一种在一个或更多个处理器上执行的自动化协同框架系统，包括：用于定义根抽象自动化模型的装置，其中所述根抽象自动化模型定义抽象数据管理方案；用于扩展所述根抽象自动化模型使得定义扩展数据管理方案的装置，其中扩展步骤是根据从用户接收的控制解决方案；以及用于实现具体自动化模型的装置，其中所述具体自动化模型根据所述抽象数据管理方案和所述扩展数据管理方案得出。

根据第三方面的方案，进一步包括用于在第一具体自动化模型和第二具体自动化模型之间共享数据的装置。

根据第三方面的方案，进一步包括用于促进多个代码执行的装置，其中用于所述多个代码执行中的至少两个中的每一个的源代码采用不同编程语言。

根据第三方面的方案，其中用于所述多个代码执行中的每一个的源代码利用了以下编程语言，所述编程语言包括梯形图、功能块图、顺序功能流程图、指令列表、结构文本、C、C++以及.netC#。

Claims (7)

1.一种用于提供自动化协同框架的方法，包括：

采用执行计算机可执行指令的处理器来执行包括以下的操作，其中所述计算机可执行指令被实现在至少一种非易失性计算机可读介质上：

生成抽象自动化模型，其中所述抽象自动化模型定义包括多个通用数据对象的抽象数据管理方案；

将多个具体自动化模型链接到所述抽象自动化模型，其中所述多个具体自动化模型中的每个分别从多个相应于供应商的编程接口中的一个相应于供应商的编程接口产生，其中各个具体自动化模型提供从相应于供应商的编程接口到所述抽象自动化模型的通用数据对象的数据接口；

接收程序，所述程序包括根据所述抽象自动化模型的通用数据对象；以及

使用所述具体自动化模型将所述程序实施为工业控制器的工业控制程序，其中所述工业控制器用于控制具有相应于供应商的组件的工业处理。

2.根据权利要求1所述的方法，进一步包括扩展所述抽象自动化模型以包括扩展的数据管理方案，所述扩展的数据管理方案包括多个相应于现有应用的项目格式。

3.根据权利要求1所述的方法，其中所述抽象自动化模型采用来自多个相应于现有应用的项目格式中的元件。

4.根据权利要求1所述的方法，其中所述通用数据对象包括声明数据对象、命令式数据对象和图形数据对象。

5.根据权利要求1所述的方法，进一步包括生成特征矩阵，所述特征矩阵根据许可允许来动态地使能、禁止、示出或隐藏所述抽象自动化模型和具体自动化模型的元件。

6.一种用于提供自动化协同框架的系统，包括：

用于生成抽象自动化模型的装置，其中所述抽象自动化模型定义包括多个通用数据对象的抽象数据管理方案；

用于将多个具体自动化模型链接到所述抽象自动化模型的装置，其中所述多个具体自动化模型中的每个分别从多个相应于供应商的编程接口中的一个相应于供应商的编程接口产生，其中各个具体自动化模型提供从相应于供应商的编程接口到所述抽象自动化模型的通用数据对象的数据接口；

用于接收程序的装置，所述程序包括根据所述抽象自动化模型的通用数据对象；以及

用于使用所述具体自动化模型将所述程序实施为工业控制器的工业控制程序的装置，其中所述工业控制器用于控制具有相应于供应商的组件的工业处理。

7.根据权利要求6所述的系统，进一步包括用于扩展所述抽象自动化模型以包括扩展的数据管理方案的装置，所述扩展的数据管理方案包括多个相应于现有应用的项目格式。