长期以来，半导体行业一直活跃在处理互操作性的接口标准化方面。即使这些标准允许半导体行业内不同的主机和设备之间的互操作性，但仍然很难使这些接口与制造业的其他领域实现互操作。工业4.0的主要支柱之一是不同设备和装置在多个领域以及操作和信息技术之间的互操作性。虽然OPC-UA正在成为工业4.0的事实上的架构，但半导体设备制造商需要遵守现有的SEMI标准，以确保其设备的销售。在这种情况下，这项工作的主要目标是开发一个全面的SEMI通信接口的元模型。作为次要目标，想用这个模型对使用OPC-UA作为半导体行业的通信架构进行初步试验，保持对既定SEMI标准的最大遵守。
SEMI标准主要涉及到通过制造执行系统(MES)(也称为主机)远程控制和监测车间的设备和装置。这样，半导体制造厂就可以保持一个灵活的生产过程，一个设备可以对生产中的各个批次执行不同的工艺。在这种情况下，SEMI标准提供了设备和主机接口的规格。然而，像许多其他标准一样，这些规范是文本的，缺少采用模型驱动工程(MDE)解决方案的领域的(元)模型。从现有的领域概念生成OPC-UA规格化模型，需要对领域进行建模，这是第一步。在这些模型的基础上，人们可以着手解决诸如模型转换、模型编织或模型联盟的问题。在这项工作中，对半导体通信接口的建模做出了贡献，然后将这个模型映射到OPC-UA信息模型中。我们的方法有两个方面的创新：1）首次尝试用多层次的建模方法对半导体标准进行建模；2）测试半导体行业采用OPC-UA架构的初步可行性，同时确保最大限度地遵守现有的SEMI标准。
A.半导体制造
SEMI制定了一系列标准，适用于半导体制造业的不同方面。这些标准可以用四个不同的架构层进行分类：物理协议层、逻辑协议层、消息定义层和应用模型层，如图1所示。物理协议与其他使用RS232和以太网的企业和工厂网络相同，并为逻辑通信提供基础。SEMI标准(图1中的阴影圆框)是在物理协议层面的基础上制定的，以规范逻辑接口。
图1.SEMI标准栈的模型
在应用模型层面，GEM300(300mm晶圆行业的通用设备模型)定义了一套标准，共同描述了半导体制造设备自动化支持的行为和通信能力。这种行为和能力是通过涉及SECS-II信息的方案来确定的。在一般设备标准的基础上，SEMI为个别类别的设备制定了SEM(SpecicEquipmentModel)标准，例如Prober、Handler。各个供应商可以在E5标准、GEM300标准或SEM标准的基础上制定自己的标准。通过采用个别标准或像GEM300这样的一套标准，可以确保不同程度的合规性。
B.运行实例
SEMI标准栈(也称为SECS/GEM栈)管理着主机和设备之间的通信。这种通信是由两者之间交换的一连串的消息来进行的。GEM标准提出了一个状态转换模型来描述设备的行为。主机可以使用消息来发送命令以控制设备的行为，这被称为远程命令。我们将使用一个请求和响应信息的序列，即远程命令请求信息(Listing1)和远程命令响应信息(Listing2)，作为一个例子，会在其余部分演示所提出的方法。
Listing1.远程命令请求消息
Listing2.远程命令响应信息
像许多其他领域一样，半导体制造业使用的标准是文本的，几乎没有正式的模型规格化。在这种情况下，很难实施任何自动机制来保证对标准的遵守。一种方法是在这些标准的基础上开发一个元模型，然后在工具的实施中符合该元模型。这样的元模型很少被共享，因为大多数元模型是直接用编程语言开发的，最终成为解决方案提供商的实施工具的核心。
为了对SEMI标准提出的通信机制进行建模，我们需要考虑E5中定义的SECS-II消息结构和E30中的通信场景概念。E173提出了一个基于XML的SECS-II消息符号的语法，用于记录目的。仔细观察SECS/GEM标准，可以发现典型的多层次建模问题，即标准的一部分是概念的实例，另一部分是类型。UML作为一种语言遵循严格的建模结构，一个模型可以驻留在四个预先规定的抽象层次中的一个。在这种情况下，多级建模方法，如powertype建模和深度实例化，提供了开发一个穿越多个抽象层次的模型的灵活性。powertype建模中的clabjects概念试图为一个同时具有类和对象的概念建模。我们使用这个概念为SECS/GEM标准中的部分实例化的概念建模。
图2.SECS/GEM通信的多层次模型
利用powertypes的概念，我们在三个不同的抽象层次上为SECS/GEM建模，即元模型、方法和项目，如图2所示。
元模型层面提出了三个核心概念，以确定半导体行业的通信和控制语言，即事务、消息和数据项。事务是主机和设备之间的双向通信，涉及一个请求信息和一个响应信息。一个事务的请求和响应消息共享同一个txid(transactionID)。元模型中的消息概念是由两个类来定义的，其中SECSMessage是SECSMessageKind的一个权力类型。这意味着，在较低的抽象层次上，SECSMessageKind的实例将作为对象面，SECSMessage将作为类面，形成一个可以对E5标准的特定部分实例化的消息进行建模的类对象。
模块化属性决定了消息是否可以作为单个块或多个块被发送。方向属性描述了消息是否可从设备发送到主机、主机发送到设备或双向发送。replyOption属性确定了当前消息的响应是否是强制性的、可选的或禁止的。异常属性描述了发生错误时的返回值。itemStructure列表说明了消息实例可包含的数据项的描述。SECSMessageKind通过指定可在方法层面上实例化的属性来确定消息对象的面，也就是说，这些属性的值已经由SEMI标准规定了。SECSMessage通过指定可在项目层面上实例化的属性来定义消息类对象的类面。最后，SECSMessage和SECSMessageKind的实例共同构成一个完整的消息实例。
DataItem类，作为一种权力类型，在项目层面上被实例化。为了支持数据项的层次结构，CompositeDataItem的项目属性遵循复合设计模式。在BaseDataItem的情况下，该项目是由格式属性所指定的类型。一个数据项实例可以有DataItemKind的allowedFormats列表所允许的任何格式。在我们运行的例子中，项目层面的mcd数据项是一个ASC(20)，即方法层面允许的格式之一。
通过对SECS/GEM标准的多级建模，我们可以看到，方法层的clabjects通过部分实例化的概念来确定消息类型。在这个层次上，消息类的对象面是SECSMessageKind的实例，而类的面是SECSMessage（图2中的SECSMessageAlias是表示类对象的语法糖）。在项目层面，这些clabjects被用于开发主机和设备之间交换的消息实例。一个完整的消息实例将重新组合SECSMessageKind和SECSMessage的实例。例如，s2f41实例消息可以访问s2f41K和s2f41P实例的所有属性。在图2的项目层面，我们看到这个消息实例向设备发送远程命令"PP-SELECT"，参数名称为"ppexecname"，参数值为"Recipe"，采用E5标准描述的树状格式。
A.框架结构
如前所述，具有OPC-UA能力的设备可以通过本地OPC-UA接口或使用OPC-UA网关来集成。到目前为止，还没有针对半导体领域的OPC-UA配套信息模型，在这种情况下，设备制造商集成一个本地OPC-UA接口的成本和风险都很大。在初步评估中，认为通过SEMI/OPC-UA网关将半导体设备连接到工业4.0的第二种选择，作为SEMI本地接口的一个封装，是一个更好的选择。在这个架构中，两个传统系统(主机和设备)可以使用OPC-UA相互通信。它还允许这些遗留系统与其他OPC-UA兼容的系统进行通信。
半导体行业的一个典型架构有一个主机，通过SEMI接口远程控制设备。它们之间的通信是双向的，可以由主机或设备发起。通信是一个请求信息和响应信息的事务。例如，主机可以向设备发送一个命令。在执行结束时，设备将向主机发送一个确认信息。以同样的方式，设备可以通过发出警报或发送报告或事件通知来启动通信。
在提出的架构中，如图3所示，OPC-UA封装组件被用来封装客户端和服务器端的SEMI接口。封装器被用来翻译SEMI消息。为了进行通信，服务器需要公开可以被客户端访问的服务。所有由设备暴露的服务都被翻译成EquipmentServer封装器，并加载到它的地址空间，从而使主机有可能通过HostClient封装器访问它们。所有由主机暴露的服务都被翻译成HostServer封装器，并加载到它的地址空间，从而使设备能够通过EquipmentClient封装器访问它们。一旦服务暴露在各自的地址空间中，客户端封装器可以翻译SEMI接口的请求消息，并从OPC-UA服务器调用相应的服务。请求(纯线箭头)和响应(虚线箭头)消息共同构成一个事务。
图3.OPC-UA封装结构
B.模型映射
对于围绕SEMI接口的封装组件的开发，目标是能够转换OPC-UA地址空间的消息。使用模型驱动的工程技术，这些封装组件可以执行转换，部分地生成OPC-UA地址空间。
一个OPC-UA客户端和服务器，作为围绕SEMI接口的包装组件，存在于图3所示架构的每一端，因为OPC-UA不允许服务器启动与客户端的交互。服务器维护其地址空间，并响应客户端发送的请求。如果一个客户端订阅了一个事件或正在监测一个变量，服务器可以通知它。另一方面，在半导体通信模型中，一个消息可以从主机端或设备端发起。对于每一端的服务器和客户端组件的实现，客户端被嵌入到服务器的实现中。使用这种方法，服务器在网络中仍然可以被发现，而且它们反过来可以通过嵌入的客户端发起与网络其他节点的互动。嵌入服务器的客户端可以直接访问服务器的地址空间，因为两者都是作为一个单一的应用程序实现的。
OPC-UA信息模型的元模型在UML中开发，在OPC-UA规范的第3部分中被定义为附件B。OPCFoundation还提供了一个开源的模型编译器，用于从符合UAModelDesign.xsd中定义的模式的模型中生成C#代码，该模型被序列化为一个XML文件。为了促进模型转换，开发了一个基于半导体标准的OPC-UA通信信息模型，该模型可以被序列化为符合该模式的XML文件。该信息模型的图形视图在图4中描述，其中图例显示了该模型中使用的OPC-UA元模型的元概念。
图4.SEMI消息事务信息模型
从多级模型到OPC-UA信息模型节点的各个元概念的映射见表I。每个事务，作为一对请求和响应消息，被映射到信息模型的SemiTransaction方法。OPC-UA的每个方法节点定义了两个属性，即inputArguments和outputArguments。这些属性被用来给方法提供参数和定义返回类型。在我们的实现中，我们映射请求信息的参数，以确定一个可以作为SemiTransaction方法的inputArgument的类型。同样地，我们映射响应消息的参数，以确定一种类型，可作为SemiTransaction方法的outArgument。
SEMI通信架构的多级模型和相应的OPC-UA信息模型之间的这种映射允许在两个模型之间进行双向模型转换。映射的实现方式是没有信息保持"未转换"。这确保了相同的模型可以从反向转换中重新生成。这种双向映射允许以一种方式开发架构，即SEMI信息可以被转化为丰富的OPC-UA地址空间，OPC-UA地址空间可以被用来生成SEMI信息。
OPC-UA在制造领域的应用仍处于初始阶段。在过去的几年里，不同的配套信息模型被开发出来，它们现在可以在OPCFoundation网站上找到。其中大多数是由主要企业和组织组成的工作组制定的。
在半导体行业采用工业4.0方面的工作不多。在一项评估中，用工业4.0的观点描述了半导体行业在生产调度方面的挑战。这项工作的范围仍然是非常狭窄的生产调度技术，没有考虑到更广泛的通信接口和互操作性方面。在以前的工作中，设计了一种方法来映射SECS/GEM通信的UML模型到OPC-UA信息模型。然而，建议成立一个由半导体领域的不同参与者组成的工作组，以规范OPC-UA中SECS/GEM标准的所有层次。
在另一项这样的工作中，解释了UML模型如何被用来生成OPC-UA地址空间，他们将其技术应用于智能电网语义。使用UML来捕获领域语义是一种自然的方法。然而，UML是基于两级类型/实例的二分法，它强加了建模的刚性。事实上，这种二分法使得SECS/GEM消息的建模相当困难。因此，没有使用UML，而是使用了一种多层次的建模方法，可以在标准层处理部分实例化的模型。通过这种多层次的建模方法，对概念的实例面和类面都进行了建模。使用这种建模技术，描述了一个考虑到这种部分初始化的模型映射到OPC-UA。
对半导体制造业的通信接口进行了建模，并进行了初步试验，以使用OPC-UA标准进行半导体行业的通信，最大限度地符合现有的SEMI标准。为了与SEMI标准保持一致，没有从头开始开发一个信息模型，而是选择改造SEMI标准。在评估中，遇到了两种可能的架构选择，即生成一个OPC-UA接口，或用OPC-UA接口封装SEMI接口。最后选择了封装选项，因为它适合于初步实验。