关于InTouchHMI与ArchestrA集成.docx
《关于InTouchHMI与ArchestrA集成.docx》由会员分享，可在线阅读，更多相关《关于InTouchHMI与ArchestrA集成.docx（25页珍藏版）》请在冰点文库上搜索。
关于InTouchHMI与ArchestrA集成
P2介绍：
本文件是用来作为一般系统的设计向导。
作为一个指导方针，提出一套最佳做法。
一个简单的搅拌罐，作为一个参考应用附在本文件的后面-这种应用是本文档中所有例子的基础。
P3快速参考
最佳做法：
绝不直接从顶层物体中实例化对象
最佳做法：
在实例化之前，模板应始终保持至少包含有一个基础层、一个控制层、一
个应用层
最佳做法：
使用“A#_”为每一个应用级或者预应用级对象创建一个索引，其中的#就是索引号。
最佳做法：
在图形工具箱里创建独立的图形
最佳做法：
当嵌入的图形创建出的新的特性符合已嵌入的图形的需要时，允许通过（即允许
该特性的创建。
最佳做法：
使得嵌入式图形具有私有性质
最佳做法：
在GR上的启动系统的地方创建一个系统区域，并在这个区域运行所有的系统对象。
最佳做法：
对货柜里的容器以他们的作用或者功能进行命名
最佳做法：
对所有脚本进行命名时，用“SCRIPT”作为前缀名，并加上描述名
最佳做法：
对所有的工具包进行编号
最佳做法：
只对应用层的对象进行实例化
最佳做法：
对应用层进行开发时，隐藏其他的层（基础层和控制层）
最佳做法：
如果某一个标志在库中已被作为某一种标准符号，应该对该标志进行更改，对该标志进行复制，并使用这个复制哦标志。
如果没有做什么改变，就直接使用这个标志。
最佳做法：
使用银河加载函数创建多个实例。
最佳做法：
当使用银河加载函数创建对象时，仅使用必需的工具
P5
A术语定义
对在本文档中使用的术语进行定义
Application
例如一个具体的实施或者一个特定的项目或网站或PLC执行。
Area
这指的是一个工厂的一部分，例如搅拌区。
Enterprise
这是指完整的企业，比如一家奇异家具店。
一个企业可以包含几个位所。
Site
这是指一个工厂的物理位置，例如约翰内斯堡工厂。
一个位所可以包含几个区。
P6
B一般设计准则
这份文件是专为系统集成商和最终希望执行系统平台的用户而设计的。
它采取以下版本：
应用服务器3.0和InTouch10.0版。
一个系统平台的执行部分的两个主要部分是：
功能部分和可视化部分。
功能是通过一堆对象实现的。
图形可以是独立的或作为这些对象的一部分实施。
这些实现单独审查。
1、设计理念
1.1.模板理论
在银河系的对象是从模板中实例化的。
当第一次创建某一个星系时，只有一小部分可用的模板（如用户自定义的，区域的，WinPlatform等）。
这些对象是在一个星系的最高水平的对象，不能被修改。
他们被称为顶级对象。
顶级对象分为三种：
●应用型——用于设计应用程序；
●系统型-----用于为系统分类对象
●设备集成型——用于可编程控制器或者场通信
注意，在应用程序工具箱中有几个顶级对象，最重要的一个是$UserDefined。
对于现场设备，建议在类似$Float等一些模板上使用$UserDefined对象。
最佳做法：
绝不直接从顶层物体中实例化对象
最佳做法：
在实例化之前，模板应始终保持至少包含有一个基础层、一个控制层、一
个应用层
1.1.1基本对象
基本对象是由顶层对象派生出来的，由于顶层对象不能改变，在顶层中提供了一个可以由用户自定义的模板。
基本对象以“b_”为前缀，例如$b_UserDefined.对于整个银河星系（系统）来说，在顶层创建的目标函数是全局函数。
1．1.2控制对象
控制对象是企业的标准。
控制对象以“m_”为前缀。
控制对象是来自基础对象（而不是顶层对象）。
控制对象可以是S95标准（如：
$m_ProcessCell），S88手机标准（如：
$m_ControlModule）或企业特殊标准（例如，在企业中的所有部分被使用的代表实物资产的对象，并标注为：
$m_LIMS）。
控制对象也可以是上述对象的更低一级的衍生品，但不应该包含Application1特定功能（如：
$m_Valve）。
通常的IO任务可以被看作是特定的应用，（因为不同场所/不同的应用程序可能有不同的PLC）。
IO任务可以出现在控制模板上，但是，这个任务的分配方法应当标准化。
注意，如果一个复杂的对象必须标准化后才能适用于所有应用程序，它应该建立在控制层。
这意味着，控制层模板已经是一个能包含对象的对象容器。
1.1.3应用层对象
应用类型的对象是针对某一个应用的，它可能是针对某一种功能或者某一种可编程控制器。
应用型对象是以“a#_”为前缀，且通常是由控制对象型对象。
在前缀中的#应该表明对应的应用。
在一个项目代码中，应用级对象将被用于实例化对象。
这意味着，应用级对象可以包含对象。
P8
如果应用程序中要使其他级别的控制对象具备某些特定功能（例如：
输入输出赋值），则需要派生。
换句话说，如果在这种应用程序中的所有阀门有共同点（例如：
PLC寻址），但在企业中的其他应用程序的阀门是不一样的，此时我们需要一个“$a＃_”类型的阀门。
在这种情况下，派生情况如下所示：
在下面的例子中，系统集成器A（SIA）设计了一个带搅拌器的混合箱，该设计中使用了他们的自定义代码（$a0_Agitator）。
他们所设计的自定义代码自己的搅拌器。
后面的系统集成器B（SIB）为公司设计了一个反应器——它也需要一个搅拌器，但是这里的搅拌器不同于SIA中的搅拌器。
尽管这两个系统集成器以m_Agitator进行标准化，但是他们对m_Agitator进行了不同的操作。
1.2图形设计理念
在进入图形设计之前，必须认识到，虽然对象可以派生和更改，图形并不能派生。
已经存在的图形只能嵌入到其他图形，但更改对图形没有影响-即可以对嵌入式图形唯一能改变的是它的公有属性。
为了确保良好的重用性，因此建议大多数的图形应该在对象的外部进行设计—也就是：
在图形工具箱中进行设计。
设计所需的带有公共属性的图形时，将内部属性变为私有性质。
换句话说：
就是使这些图形自足（独立的）。
P9
每当将图形嵌入到一个新的图形时：
为所有使用的属性（并将其设为默认值）创建新的属性。
将嵌入的图形的属性附加到最新创建的属性中，并将它们设置为私有属性。
2、设计中应注意的问题
2.1模型
对于顶层来说，建议最好为建模建立一个标准，该标准要符合S95标准。
这一概念在IDE中显示过
P10、P11
模型设计旨在模拟工厂的物理布局（版图设计），例如，一个混合器中包含一个搅拌器、一个进气阀、一个出口阀、一个液位变送器、一个进口和出口流量变送器、一个PID控制器和一个水泵。
一个水泵包含一个流量变送器和一个压力变送器。
大致的图形显示于下页。
在应用服务器中，这些容器可以表示为：
这里的想法是在主对象中包含“子对象”。
这样做的好处有：
●可以形成便于理解的格式（样式）
●包容性
Ø如果有人想读取读取某一层的特定的混合箱（比如MixingTank_005）,它可以被标记为MixingTank_005.Level.P.V.他/她不需要知道这一层的传送器是Level_001.
Ø一个特定的混合箱可以使用在它下面标识为“me”的对象。
例如，当需要查看混合箱对象里的脚本级别时，可以参见me.Level.P。
这意味着，对于不需要为每一个混合箱单独编写脚本——换句话说：
如果同一个脚本运行在所有的混合箱中，每个混合箱将会得到它们自己的级值。
Ø一个子对象可以用mycontainer来定义它的容器。
例如，如果泵中需要一个脚本是用来检查混合箱是否处于初始条件，它可以定义为mycontainer.Status.Starting。
这意味着，不需要知道这特定的泵是混合箱004的一部分。
符合给定要求、精心设计的模型进行实施和维护非常容易，如果一个模型，精心设计，并符合要求，实施就包括拖动模板到模型空间，运用正确的命名规范，右键单击并放置它。
如果可能，应该在模板层尽量符合给定要求。
为一个混合箱设计的模板应该包含泵的模板，泵的值等等。
当一个新的混合箱添加到模型中，混合箱中包含的对象应该同时添加到该模型中。
可以注意到，容器的命名对于容器的工作的高效性是非常重要的。
2.2派生
当运用派生时，我们应该主要牢记的是派生物与被派生物之间有类似的功能。
在我们上面所举的例子中，我们提到两个完全不同的电动机（一个搅拌机和一个泵），但是他们具有相同的功能。
所有的电动机可能都有一个启动和停止以及状态指示（指示它是否在运行）功能。
这些功能可以都归结为一类$m_Motor。
当需要任何类型的电动机时，可以从模板中派生出一个，派生出的电动机就具备需要的功能（包括脚本功能）。
将派生这一概念继续延伸，就可以实现得到两个不同类型的电动机：
一个泵和一个搅拌器。
这个$m_Motor模板可以用来派生出两个新的模板：
$m_Agitator和$m_Pump.这两个新模板可以直接在原模板中使用，或者还可以直接派生出混合箱特别版本（例如$a0_MixingTank.Agitator）。
如果遵循在模板中建立容器的准则，这样确实比在混合箱模板中加入混合箱特定版本要好很多。
使用派生结构图来形象描述派生。
留意上面所举的例子可以看出，$m_Agitator的混合箱特别版被叫做$a0_MixingTank.Agitator.$a0_MixingTank这部分确实被定义为$a0_MixingTank模板。
Agitator已成为模板的一部分。
2.3部署
尽管ArchestrA模型是从基础结构中单独设计出来的，但是对对象的部署进行考虑也是非常重要的。
对ArchestrA进行部署需要一台PC或者服务器，这是一个从$WinPlatform派生出的对象。
执行对象需要引擎。
存在两种类型的引擎：
●$AppEngine（应用型引擎）用来执行对象。
●$ViewEngine用来执行客户端应用程序。
引擎必须部署在平台上。
应用型引擎可以直接运行设备集成对象。
他们还可以执行正常的对象，但这些对象都必须在一个区。
“这些对象都必须在一个区”这一点很重要，因为他们必须被同一个的应用型引擎执行，因此在同一台服务器上。
在客户端－服务器组合中，服务器通常会运行一个$WinPlatform和至少1个$AppEngine对象。
客户端机器将有一个$WinPlatform和一个$ViewEngine。
在独立的环境中只有工作站机器运行$WinPlatform、至少一个$AppEngine和一个$ViewEngine。
还要建议的是，至少一个顶级系统区域应该部署到GR上。
此区域应包含模型框图（包括所有的平台和发动机）中所有的系统对象。
这就要求GR至少有一个应用型引擎。
P13
还要建议的是，至少为以下平台建立$b_WinPlatform的派生体：
●GalaxyRepository（GR）
●应用服务器
●操作员平台模块
3.命名约定
3.1对象命名
所有对象都至少有一个标记名称。
容器类对象也有第二个名字叫Containedname。
在ArchestrA系统中定义的第一个对象必须是一个标记名称，除非相应的保留字（如me，mycontainer，myarea，myEngine等）被使用了。
每一个定义中只能使用一个标记名称。
举个例子：
ATagname.ContainedName1.ContainedName2.ContainedName3.Attribute。
一个标记名称是用来标识一个对象的-与其他对象不可能具有相同的标记名称。
一个标记名称唯一标识系统中的一个对象。
强烈建议建立一个稳定的命名约定。
这方面的一个很好的例子是ANSIISAS5.1/1984（R1992）。
一个Containedname唯一标识带容器的对象-在系统中的其他对象中可能具有相同的Containedname，但他们不能在同一容器中。
用Containedname来描述容器的功能是可取的，例如Fan_Motor，Jacking_Oil_Pump，Inlet_Valve等等。
3.2属性命名
属性（不论是域属性或用户自定义属性）是对象的公共接口。
建议建立一个强大的命名约定。
这种约定已经描述过所述，有时可能需要根据应用/实施做一些变化。
在（[]）方括号[]内的名称部分是可选的。
斜体部分名称……
P14
3.3脚本命名
在所有的脚本加一个前缀进行标识（如：
“Script.”或者“Scr.”），脚本的其余命名应该具有描述性，可以用点符号进行分离。
例如，如果脚本计算属性结果值，使用Script.Status.State.Calculation.
P15
C.工具箱的设计
工具箱设计指南
4.派生
模板应该合理安排并易于浏览。
建议创建三种类型的工具箱：
●基本对象
●控制对象
●应用型对象
这些工具箱对应三种推荐类别的派生（详见2.2小节的“派生”部分说明）
4.1基本型
一般情况下，基本对象工具包将包括少量的对象，这些对象将成为系统的基础。
可以把这些对象组织起来形成一个子集，但这样做非但不能帮助开发，反而会限制开发者。
这些组织可以在这个子集，但可以减缓开发商多于帮助。
4.2控制型
在控制层中，将对象打包起来放到一个子集中是很有用的。
建议建立的子集有：
●针对所有系统对象的系统模板集合
●针对ISA95架构的S95模板集合
●针对所有控制层控制模块的控制模板集合
●针对所有控制层变送器的变送器集合
P16
也可以创建附加的工具箱。
用描述性强的名字对工具箱进行命名和编号，这样便于我们在需要时寻找到这些模板。
应用服务器3.0允许工具箱嵌套，这样可以实现更多层次的阶层式结构。
P17
4.3应用型
如前所述，应用程序级的对象应该是针对用于实施的应用程序/项目。
通常会有一个为不同类型的部件（例如工具集搅拌罐）而准备的工具箱。
在所有地方保持工具箱的数量相同使得模板间的切换比较容易。
5.实例化
5.1一般实例
为了保持一致，建议只有应用程序级对象被实例化。
这意味着，如果直接需要来自控制层的对象，应该在实例化变成其他级别之前就要对对象进行派生。
这样做有时似乎没有必要，但有时是确保再用性，同时为进一步的扩展保持足够的灵活性的唯一途径。
P18
5.2系统区域
如前所述，创建系统区域用来包含模型图中的系统对象。
换句话说—在未分配的区域中没有部署对象。
系统区域可以被部署在GR节点上的一个引擎上。
P19、P20
D.图形设计
图形设计指南
一个好的做法是创建4个级别的图形，即：
标准图形、弹出式图形、特定对象图形、概述图形。
6.标准化图形
标准化图形确定按钮造型，面板风格等。
独立按钮、面板等这些东西使他们可以嵌入到任何其他图形并发挥相应的功能。
要想更改整个应用程序的外观和感那么只需改变这些标准化图形就可以了。
这方面的一个很好的例子是，例如在应用程序中按钮的标准化：
在这个例子中绘制的标准化按钮具有三个公共有属性：
●灰度化值（布尔型）——用户可以设置此值对按钮进行灰度化。
●鼠标指向值（布尔型）——当鼠标指向按钮时，用户可以用脚本给它赋以正确的值。
●按下值（布尔型）——当按钮被按下时，用户可以用脚本给它赋以正确的值。
一个单一的内部属性存在：
高亮性。
如果鼠标指向按钮，高亮的布尔值就被设置为真（MouseOver=TRUE）并且按钮没有被灰度化（GreyedOut=FALSE）。
为实物资产设置的符号也可以标准化—例如，一幅带有所有容器的动画图片的泵的图片。
请注意，标准不应该注重对象。
还可以建立以下标准：
●面板
●文本框
●标题
●面板中的灯光类型
●开关
●等等
从已建立的标准可以产生其他的标准，同时提供一个图形函数，这个图像函数可以被不同的应用程序、对象或者图形重复使用。
最好的例子就是一个自动/手册切换器—这种切换器可以作为标准按钮和文本使用，但是它完全只显示两种最原始的属性（自动和手册）。
一个statistics面板最为例子进行展示。
这个面板可以被不断地重复使用，当需要一些值时，只需将这些值显示在面板上即可。
在对象的外部建立标准时，有一个值得注意的例外情况（特例）就是当需要使用NameAnimation时。
这个NameAnimation需要将对象直接与工作相连接。
这个NameAnimation可以在$b_Userdefined中完成。
标准也可以是对象标准图形（符号），例如一个泵、vaval、或者一个发动机。
注意属性的使用：
BladeCount属性被设置为18（一个常数值）并被设为私有属性——这个也变成了标准的一部分。
例如，所有使用这个泵标准的图形都将使用18个Blades（刀片）。
属性值变成私有，使用者必须将这个属性与正确的标签连接起来——这里默认提供的是me.Status.Running。
7.弹出窗口
结合标准创建通用的弹出窗口。
变送器的弹出窗口显示如下
我们可以看到，弹出窗口有一系列属性需要与标准中的属性相连接并
应该设置为私有。
8.特定的图形对象
代表现场设备的对象通常只包含两种类型的图形：
第一种应该是符号代表对象（如泵的图片），第二种应该是一个组装好的弹出窗口（面板）窗口。
符号图形将包含为对象而配置的符号图形对象。
。
这些图形应该是一个嵌入式图形（标准化窗口和弹出窗口）定制组。
所有其他（可重复使用的）图形应该作为单独的图形进行设计。
特定的图形对象也可以是代表物理设备的图形。
最简单的形式，如前面描述的水泵图形东西可以直接嵌入。
这种类型的图形，也可以是图形的集合。
例如，一个水泵机组包含泵、流量变送器和压力变送器。
该水泵机组图形可以完全由一些已经存在的基本元图形的集合。
9.概述图形
这些图形显示在屏幕上，供用户察看。
这里有两种选择：
●采用特定的图形对象建立内部传统的InTouch屏幕。
●在表示屏幕的区对象中建立显示板。
这些概述性的显示板可以利用这些特定的图形对象以及标准。
E.散装对象创建
为一个对象创建多个实例
10.包含的模板
如前所述，一个模板可以包含其他模板（如混合箱包含泵）。
如果容器中有多个实例（例如在混合箱装置中有多台泵），建议在模板只出现一个实例。
应该在第一次实例化后再添加多个实例。
过程就是这样的。
实例化该模板将提供第一个实例。
后续实例可以在银河系统的加载选项中被创建出来。
有关实例可以被转储到一个具有银河转储功能的CSV文件。
删除所有不必要的collumns（我觉得是“列”的意思）然后再创建新实例的新行。
CSV文件是一个实施正确的命名约定的好地方。
升级会员 