带你轻松了解半导体CIM系统之EAP (四)

半导体CIM系统随着晶圆厂模式的盛行也历经了几十年的时间，许多公司的CIM系统还存在架构老旧，性能亟待优化的情况，这次和大家分享一篇澳门科技大学与IKAS在EAP新架构探索方面的一篇论文《A New Framework of the EAP System in Semiconductor》，以下会基于英文原版翻译与加入个人理解做一些修改。

作者： Tairan Song, Yan Qiao, Yunfang He, Jie Li, Naiqi Wu, Bin Liu

机构：

1. 澳门科技大学系统工程研究所与智能科学与系统协同实验室

2. 埃克斯工业科技有限公司

论文摘要

在现代半导体制造中，计算机集成制造系统（CIM）在自动化方面扮演着至关重要的角色，并拥有大量的软件系统。其中，设备自动化程序（EAP）是支持各类设备互联的基础系统之一。对于传统的EAP而言，其通信和逻辑模型是紧密耦合的。EAP中任何异常的发生都可能导致EAP出问题，从而使得所有设备都无法访问。此外，传统EAP通常只能处理少数几种机台。半导体工厂中随着扩产，入驻的机台也越来越多，使得EAP的变得难以承受。

因此，工厂迫切需要解决传统EAP的这些问题。为此，本研究设计了一种新的分布式EAP系统框架，采用新技术来增强EAP的可用性和稳定性。此外，这种设计理念使得分布式EAP系统更具兼容性和可扩展性。并且，随着通信和大数据技术的发展，该EAP系统可以进行升级。我们进行了实验来验证所设计的分布式EAP系统的稳定性。

1. 引言

在半导体制造领域，自20世纪90年代初以来，计算机集成制造（CIM）系统通过各种控制软件系统和传感器，帮助晶圆厂提高了生产效率和晶圆质量。借助CIM，许多任务，例如在半导体生产机台上上传和更改Recipe，都可以自动执行，而无需工程师手动控制。这极大地将工程师从复杂繁琐的日常工作中解放出来。此外，它还可以避免因在半导体生产机台上的人为不当操作而导致的晶圆质量问题和机台故障。

CIM最早由Joseph Harrington博士于20世纪70年代初提出，它是一种利用计算机控制整个生产过程的制造理念。通过这种方式，不同的操作可以很好地同步，从而大大缩短了过程的周期时间。此外，CIM使制造过程更不容易出错。据本研究作者所知，大多数半导体工厂都安装了相关的软件系统来支持CIM，例如制造执行系统（MES）、物料控制系统（MCS）、自动化物料搬运系统（AMHS）、配方管理系统（RMS）和EAP。

MES是CIM的核心部分，帮助工程师管理和控制制造环境和流程。MES因行业而异，甚至在同一家公司的不同工厂之间也有所不同，因为它需要精确反映涉及各种细节的制造流程。IBM和应用材料公司是半导体工厂MES市场的两大主要供应商。他们可以定制模式提供MES产品。

MCS负责半导体工厂内部的物料运输。实际上，MCS是根据MES下达的交付任务来运作的。MES将包括起始位置、结束位置和优先级在内的交付信息发送给MCS。然后，MCS与存储设备和天车系统协作，完成MES下达的任务。AMHS负责管理和控制运输工具，例如工厂中的存储设备和天车系统。实际上，AMHS总是与MCS合作，共同负责物料运输的整个过程。

RMS的主要作用是管理工厂中的Recipe（配方）。在现代半导体工厂中，有超过一千台用于晶圆制造的机台，例如光刻机，蚀刻机，清洗机台等等。不同的产品可能在同一机台中使用不同的Recipe进行制造。因此，可能需要管理数千个Recipe。由于涉及如此多的机台和待处理的晶圆产品，手动管理如此大量的Recipe极其困难。RMS的职责是收集和管理Recipe，以便确定何时以及应将哪个Recipe应用于特定的机台。实际上，RMS与EAP合作，在需要时向机台下Recipe。

EAP是一个基础软件系统，直接与制造机台通信，并将生产相关信息传递给更高级别的应用程序，如RMS和MES。EAP通常基于SECS I、SECS II、GEM和HSMS协议进行开发。EAP的性能对CIM中其他系统（如RMS、APC和MES）在半导体制造中的效率有显著影响。

如图1所示，传统的EAP充当生产机台和CIM中软件系统之间的单一集线器。

图1 传统EAP架构

随着工厂对数据分析需求的不断增长，传统的EAP由于以下原因无法满足当前应用程序对数据收集和信息传递的需求。

(1) 通信模型和逻辑模型之间的紧密耦合使得EAP臃肿且不稳定。例如，EAP中任何异常的发生都可能导致EAP故障，从而使得机台与EAP断连； (2) 由于EAP是多年前开发的，部署EAP需要许多软件依赖项，并且系统运行在较旧的操作系统上； (3) 传统EAP的设计较少考虑可扩展性问题，导致其只能处理少数机台。工厂中生产机台的扩充使得对EAP的性能难以承受。

随着通信和软件技术的不断进步，例如物联网（IoT）、云计算、分布式技术、大数据、容器技术以及消息队列技术，可以设计一种新型EAP来解决传统EAP的上述问题。

据我们所知，关于EAP的研究相对较少。然而，这些研究并未专注于解决上述EAP系统的问题。此外，目前半导体工厂采用传统的EAP系统与生产机台进行通信，而上述问题仍未得到解决。解决这些问题非常重要，这也激发了我们进行这项工作。

在这项工作中，我们引入了一种新的分布式EAP框架。本文提出的EAP与传统EAP之间的本质区别在于，我们提出的EAP是松散耦合的。为了构建这种松散耦合的EAP系统，我们重新设计了其架构和工作机制。在新的架构中，EAP由两个主要平台组成，即管理平台和基础平台。同时，采用消息队列进行异步通信。通过这种方式，所有模型（例如管理模型、业务逻辑模型和API模型）、中间件和EAP驱动程序都分布并部署在各种服务器上。这表明所提出的EAP的任何部分都可以独立运行。

在这样的框架下，可以增强EAP的几个性能指标。首先是抗干扰能力。在分布式架构下，整个EAP系统可以更加健壮和稳定。EAP系统中的一个小异常不会影响整个系统，与传统EAP系统进行比较，这极大提高了EAP系统的鲁棒性。其次，在容器技术的优势下，EAP系统的部署和维护变得更加容易，并且适用于更多的操作系统。第三，通过集成分布式架构和消息队列，整个EAP系统可以根据需要进行扩展。

本文的其余部分组织如下。第2节介绍了分布式EAP系统的实施框架。然后，基于该框架，在第3节中描述了系统每个部分的详细操作场景。最后，进行了实验以验证系统性能。

2. 分布式EAP系统的实施框架

2.1. IF-DEAPS的设计理念

我们根据以下三个原则设计了一种新的分布式EAP系统（IF-DEAPS）实施框架，以确保整个系统的稳定性并满足实际生产条件下的性能边界：

(1) IF-DEAPS的架构应该是松散耦合的； (2) 需要先进的软件技术来促进其松散耦合，并降低部署和管理成本； (3) IF-DEAPS必须具有良好的可扩展性，以满足智能制造的要求。

松散耦合是设计良好的分布式EAP系统的重要因素。IF-DEAPS的松散耦合架构意味着IF-DEAPS的所有功能平台应最大限度地提高它们之间的独立性。此外，如果一个有效的模型或平台在逻辑上是紧密耦合的，那么除了关键的同步情况外，大多数通信都应根据消息队列执行以实现解耦。凭借IF-DEAPS的松散耦合架构，可以根据需要独立部署服务或模型，从而增强系统的可伸缩性、灵活性和开放性。同时，IF-DEAPS可以避免单个节点故障对整个系统造成的严重影响，从而具有高度的容错性。因此，整个系统可以从松散耦合中受益。此外，这种设计模式符合当前软件开发的范式。

为了促进松散耦合，并降低部署和管理成本，IF-DEAPS采用了最新的先进技术，即容器技术。

近年来，容器技术一直是软件行业的热门话题。Docker作为一种软件平台，是容器技术清单中最受欢迎的技术之一。Docker提供了一个称为容器的标准化单元来运行镜像，开发人员可以将应用程序及其相关依赖项打包到其中。这种机制使得在各种场景（例如开发、测试和生产）中构建、传输、部署和维护应用程序变得更加容易。各种角色（包括开发人员、测试人员、运维工程师等）都可以从中受益。他们可以专注于自己的职责，而将其他部分视为黑盒。例如，测试人员可以简单地构建一个容器，并专注于接口测试和黑盒测试，而运维工程师可以花更多时间在（互联网技术）基础设施和监控系统运行性能上。

良好的可扩展性可以使IF-DEAPS更好地匹配智能制造的要求。在智能制造中，分布式EAP系统与制造工具连接的要求因工厂而异。一些工厂只需要在某些核心制造区域配备少量精密仪器来获取一些基本数据，而另一些深入智能制造的工厂则需要尽可能多地连接工厂中的所有制造工具以进行数据收集。可扩展性应主要从以下三个方面考虑：（1）连接可扩展性；（2）业务逻辑可扩展性；（3）管理可扩展性。

连接可扩展性指的是，随着工厂中制造工具数量的增长，分布式EAP系统可以与生产机台进行物理连接，而不受架构限制。业务逻辑可扩展性意味着用户部门的业务逻辑（即需求）可以轻松集成到系统中，准确转换，并在制造过程中正确执行。例如，Recipe1和2应用于工具中的一种生产机台的不同场景。在机台的实际操作中，应根据晶圆制造场景（即晶圆制造过程）正确部署它们。管理可扩展性意味着随着连接的增加，系统应该有一个地方可以正确管理和维护连接。

2.2. 架构

根据上述设计原则，IF-DEAPS的系统架构如图2所示，其中包括一个管理平台、一个消息队列和一个基础平台。在该架构中，相关生产机台和传感器被省略了。

图2 IF-DEAPS的系统架构

在该架构中，管理平台充当大脑来控制和监控整个系统，消息队列负责在整个系统中传递数据，就像大脑中的神经系统一样，基础平台则充当四肢来执行命令和收集数据。

管理平台由管理模型、业务逻辑模型、监控模型、主模型、应用程序接口（API）模型和一个数据库组成。所有这些模型都可以针对不同的用途进行分类。管理模型、监控模型和主模型用于管理；业务和API模型用于执行与业务相关的任务；数据库用于跨管理平台存储模型的数据以及可提供给其他系统的中间数据。

管理平台上组件的排序不仅基于功能，还基于系统交互。与业务相关的部分是与用户和外部系统交互的端口。因此，它应该是独立的，并提供直接、清晰的系统功能。管理平台的核心功能是监控和管理分布式EAP Driver的基础平台。为了有效地实施这些关键功能，在设计的IF-DEAPS中引入了Master Model和代Agent Model。Agent Model部署在每个EAP Driver之前，并帮助部署、配置和监控相关EAP Driver的健康状况。代理模型的数量等于EAP Driver的数量。Master Model负责与Agent Model通信以传输操作命令并收集管理模型所需的数据。

在图2所示的IF-DEAPS中，消息队列在当前软件开发行业中被广泛使用。Kafka 、ActiveMQ、RabbitMQ和RocketMQ是该领域最受欢迎的几种。通过分析这些消息队列的优缺点，Kafka被选为此架构中的消息队列。说服我们使用Kafka的原因总结如下：（1）Kafka的设计是一种自然适合高并发场景的分布式架构；（2）实施期间有良好的文档和社区支持；（3）支持多种开发语言，使得该框架没有语言限制。

IF-DEAPS的基础平台是一个松散的边缘平台，用于容纳EAP Driver。该平台的驱动程序直接连接到生产机台，以通过不同的协议（例如SECS/GEM、HTTPS等）收集数据和控制机台。如上所述，平台上的Agent Model与Master Model配对，用于监控和管理EAP Driver。接下来将描述IF-DEAPS的详细操作机制。

3. 操作机制

3.1. 基础平台

IF-DEAPS的基础平台架构如图3所示。EAP的基本功能是从机台收集晶圆处理数据，并向机台下各种命令。如图3所示，每个EAP Driver都与机台和消息队列进行双向通信。Agent Model与相应的EAP Driver关联，通过配置EAP Driver并监控EAP Driver的健康状况等方式，确保其保持良好状态。基础平台的典型操作场景，包括命令执行场景、数据收集场景、EAP Driver配置场景和EAP Driver健康状况监控场景，将讨论如下。

图3. 基础平台架构

3.1.1. 命令执行和数据收集方案

分布式EAP系统的命令执行和数据收集方案如图4所示，操作机制包括以下四个步骤：

(1) 消息队列将数据收集命令发给到EAP Driver。此类命令必须提供相应的数据信息，例如生产机台上wafer的processing参数、收集时间或其他特定要求的参数； (2) 根据半导体相关协议，EAP Driver向生产机台下达相关命令； (3) 机台执行命令后，将数据解析回EAP Driver； (4) EAP Driver收到数据后，将数据转换为JSON格式并将其发给消息队列。

步骤（1）和（2）共同构成命令执行方案，而步骤（3）和（4）共同构成数据收集方案。

图4. 命令执行和数据收集方案的操作机制

3.1.2. EAP Driver配置方案

EAP Driver配置方案如图5所示。以下五个步骤构成了此方案的操作机制：

(1) 消息队列将更新的配置命令发给Agent Model； (2) Agent Model将此更新命令发送给相应的EAP Driver，然后EAP Driver进入更新模式； (3) Agent Model从消息队列中获取最新的配置信息； (4) Agent Model更新EAP Driver配置文件； (5) 更新成功后，Agent Model将EAP Driver转为正常模式，并向消息队列发送反馈。

图5. EAP Driver配置方案

3.1.3. EAP Driver健康状况监控方案

EAP Driver的健康状况监控是在部署分布式EAP Driver之后进行的，并一直持续到EAP Driver终止。EAP Driver部署是指在服务器上初始化EAP Driver以及初始设置、配置和默认参数。EAP Driver健康状况监控方案如图6所示，此方案的操作机制包含以下四个步骤：

(1) EAP Driver部署执行后，EAP Driver向消息队列发送成功消息；
(2) 相应的关联Agent Model从消息队列获取成功消息；
(3) Agent Model检查健康状况数据，例如来自EAP Driver环境的应用程序进程ID、磁盘使用情况、网络速度等；
(4) Agent Model将健康状况数据发送到消息队列。

根据所需的监控周期，Agent Model定期重复步骤（2）至（4）。

图6. EAP健康状况监控方案

3.2. 消息队列

消息队列在两个系统之间实现了异步数据通信机制。消息队列的主要功能是数据通信，尤其适用于解耦的微服务架构。一组数据在逻辑上被视为一条消息，它们存储在队列中直到被处理。通常，消息队列技术可用于解耦重量级数据处理、缓冲工作和批处理工作，以及作为负载均衡器。

在这项工作中，Apache Kafka被选为IF-DEAPS中的消息队列。其背后的原因可以分为三点：（1）分布式结构；（2）数据流管道功能；（3）容器化且易于安装。

Kafka是一个多功能、分布式和复制的框架，通过发布-订阅过程实现消息队列。它是一个由社区维护的开源软件。在操作机制中，发布者被称为“生产者”，订阅者被称为“消费者”。生产者提交数据，消费者接收数据。Kafka的一般基础架构如图7所示。

图7. Kafka技术架构

如图7所示，生产者将消息发送到Topic。消息被称为数据。生产者一次只能将数据发送到一个Topic。此外，生产者能够异步和点对点地发送消息。消费者从Topic读取消息。他们维护分区偏移以消耗来自Topic的数据。实际数据以键值格式存储。然后，数据是不可变的。

Topic是多个消费者订阅的数据流。这是Kafka提供的最高级别抽象。分区是一个有序的、不可变的数据序列，不断附加。它不能在磁盘上进一步分裂。

高可用性由分布式架构执行，因为数据可以从多个分区获得。此外，Kafka中的容错也是通过将分区数据复制到其他代理（称为数据副本）来实现的。每个代理持有一个或多个分区，每个分区都可以是副本或Topic的领导者。在Kafka机制中，读写操作通过Topic的领导者进行，领导者与副本进行数据更新协调。

从图2可以看出，Kafka被用作EAP管理平台和这项工作的基础平台之间的主要数据管道。基础平台是数据生产者，而EAP管理平台则充当数据消费者。在内部，传输的数据在逻辑分区组中获得一个Topic进行存储。分区是数据的实际存储，数据分布在不同机器内整个集群的多个分区上。在外部，消息队列充当连接两个独立系统（即EAP管理平台和基础平台）的桥梁，以形成整个分布式EAP系统。

3.3. 管理平台

管理平台架构如图8所示。该平台是用户或其他系统的端口，这些外部部分被添加到IF-DEAPS中。Web UI和应用程序是图形用户界面，可帮助用户管理分布式EAP系统并通过该系统操纵晶圆制造工具。由于EAP系统是收集数据和操纵生产机台的基础，因此其他系统（例如APC、RMS和故障检测与分类（FDC）系统）需要通过API从IF-DEAPS获取数据。

图8. 管理平台架构

在管理平台中，管理模型、业务逻辑模型和API模型已完全或部分导出到Web UI或其他系统以提供服务。Master Model、监控模型和数据库信息主要支持服务的执行。例如，当用户在Web UI中触发数据收集服务时，Web UI然后将相关参数解析到管理模型。管理模型随后分析并将其转换为命令。命令发送到Master Model，Master Model负责执行此命令。接下来将讨论一些典型的操作场景，包括数据检查场景、更新配置场景以及检查EAP Driver状态场景。

3.3.1. 数据检查方案

在数据检查方案中，当用户想要检查设备数据（包括实时和历史数据）时，如果用户查询实时数据，则数据源应该是EAP Driver；如果用户查询历史数据，则数据源应该是数据库。详细方案如图9所示，操作机制包含以下步骤：

(1) 用户发出命令来检查一系列数据。此命令可以通过应用程序、Web UI或其他调用API服务的系统发出。此外，如果命令由其他系统发送，则传递到API模型；而如果命令由应用程序和Web UI发送，则传递到业务逻辑模型；
(2) 如果命令传递给API模型，则此命令将转移到业务逻辑模型；
(3) 业务模型分析命令，即确定所需数据是实时数据还是历史数据。如果数据是实时的，则业务模型将此命令发送到Master Model以实时从EAP Driver获取数据；如果数据是历史性的，则业务模型将此查询命令发送到数据库；
(4) 如果数据库接收此命令，则可以解决查询并将正确的数据发送到业务逻辑模型；
(5) 如果Master Model接收此命令，则分析命令，并具体说明适当的EAP Driver，用EAP参数重新包装命令，然后将命令发送到消息队列中的主题；
(6) 从EAP Driver收集所需数据并将其发送回后，消息队列将数据推向Master Model；
(7) Master Model将数据发送到业务逻辑模型；
(8) 收到数据后，业务逻辑模型根据适当的业务逻辑操纵数据，并将其相应地发送回应用程序、Web UI或API模型；
(9) 如果API模型收到所需的数据，它将从业务逻辑模型向其他系统提供数据。

图9. 管理平台中的数据检查方案

3.3.2. 配置更新方案

配置更新是指用户想要更改与晶圆制造机台类型相关的特定EAP Driver或一组EAP Driver的配置的情况。此场景如图10所示。

图10. 配置更新方案

3.3.3. EAP Driver状态检查方案

EAP Driver状态检查方案是一个持续监控的场景。在实际生产环境中，所有EAP Driver都持续受到监控。在以下描述中，仅引入一个分布式EAP Driver的状态检查方案。该方案如图11所示。

图11. EAP状态检查方案

3.4. 提出的分布式EAP系统的优势

与传统EAP服务相比，在适当的业务逻辑下与生产机台的通信和操纵在基础平台和管理平台上完全实施。此外，由于IF-DEAPS的分布式架构，适应性和可伸缩性得到了增强。

适应性的增强意味着可以用较低的成本处理异常。对于传统的EAP，任何异常，例如环境问题或传统EAP中的错误，都可能导致相应的机台离线。如果发生这种情况，则需要工程师花费大量时间来解决问题。但是，在IF-DEAPS中，如果一个EAP Driver出现故障，则只有连接到该驱动程序的机台会受到影响，而其他机台仍然可以正常工作。此外，由于采用了容器技术，可以快速重新部署发生故障的EAP Driver，从而最大限度地减少对生产的影响。

可伸缩性的增强意味着IF-DEAPS可以轻松适应工厂中机台数量的变化。当需要连接新的机台时，只需部署一个新的EAP Driver并将其注册到管理平台即可。当不再需要某个机台时，可以轻松地从系统中删除相应的EAP Driver。这种灵活性使得IF-DEAPS能够适应不断变化的生产需求。

4. 性能评估

分布式EAP系统性能测试的目的是评估整个系统的稳定性以及在实际生产条件下性能边界。在此工作中，使用Jmeter工具进行这样的性能测试。表1列出了两个相应的短期和相对长期测试场景。表2显示了测试环境。此外，还使用9个指标来评价EAP系统的性能，包括：

（1）请求成功比率：成功接口请求响应的总请求比率；

（2）CPU消耗(CPUC)：EAP系统性能测试期间的CPU资源消耗；

（3）内存消耗(MC)：EAP系统性能测试期间的内存资源消耗；

（4）TB-90%：数据请求响应时间的90％的时间边界；

（5）TB-95%：数据请求响应时间的95％分位数的时间边界；

（6）TB-99%数据时间边界：不低于99％请求响应时间的数据的时间边界；

（7）最小时间消耗（MinTC）：接口响应的最小消耗时间；

（8）最大时间消耗(MaxTC)：接口响应的最大耗时；

（9）平均时间消耗(ATC)：接口响应的平均时间。

测试场景及测试环境：

对于场景A和B，分别对EAP系统进行24小时、3×24小时的9个关键接口请求-响应数据观察性能测试。场景A和B的具体测试结果总结在表3和表4中。  

如表3和表4所示，所有接口的请求成功率达到100%，同时CPU和内存资源消耗控制在70％以内，在应用中处于安全可控范围。具体来说，从表3和表4可以看出，对于所有接口而言，TB-90％、TB-95％和TB-99％均在毫秒级范围内，且A场景下参数设置及参数比例下的值大于B场景下对应的值，这表明在相对短时间的A场景（即A场景中的数据响应时间不低于90％、95％和99％的时间边界）下，其数据响应时间比B场景（即B场景为相对较长时间段）要长；因此，本文提出的分布式EAP在更长的时间内具有更加稳定的性能，因为较长的数据响应时间占总响应时间的比例下降了。 

此外，大多数情况下，在场景A中MinTC的值比在场景B中的大，而每个接口下场景B的最大时延（MaxTC）的值大于场景A。这种现象的原因是，在更长的时间段内，极端情况下的异常数据收集概率更高。请注意，表3或表4中最大时延值代表的是网络抖动引起的常见异常事件。然而，从表3和4可以看出，除了参数设置和参数比例设置接口外，场景A和场景B之间的ATC值没有显著差异。对于参数设置和参数比例设置接口，场景B的ATC值远小于场景A。这表明分布式EAP可以在更长时间内实现更加稳定的表现。 

综上所述，根据表3和表4中RSR、CPUC、MC、TB-99% 和ATC的测试结果总结得出，在两种场景下提出的分布式EPA系统均具有良好的性能。

此外，参数接口对于分布式EAP系统管理平台中的组件获取生产机台的参数数据至关重要。它是生产环境中被频繁调用的接口之一。从图12和图13可以看出，代表参数接口的浅绿色线的变化通常比较平滑，这表明分布式EAP系统运行正常，并且在响应方面表现良好。偶尔也会出现一些浅绿色线的针状跳动现象，这些通常是由于网络问题或计算资源竞争问题造成的。请注意，它们与分布式系统本身无关。同时，即使偶尔出现问题，该系统也可以按照要求正确地进行响应。

表3和表4显示了所提出的分布式EAP系统的稳定性。此外，还获得了与目前采用的来自其他三家半导体制造软件公司的EAP系统进行比较的一些定量结果。在保密和商业法规下，我们无法披露其他软件公司的名称，并将其命名为公司A、B和C。比较是在中国的一家半导体工厂的同一生产线中进行的。比较结果如表5所示，在其中TPS表示每秒事务数。由于与半导体厂签订了非披露协议，因此不能展示详细的定量比较结果。然而，每个方法可以达到的TPS数量级如表5所示。从表5可以看出，IF-DEAP在TPS效率方面明显优于其他方法。   

5. 结论

EAP系统被广泛用于互连制造设备，从而将相关生产信息解析并传递给半导体工厂的上层应用。它们也是MES与机台交互的桥梁，在RMS、APC等其他系统的高效运行中发挥着重要作用。传统EAP作为单一节点互连指定数量的机台，缺乏可扩展性。其通信模型与逻辑模型紧密耦合，导致系统臃肿且不稳定。此外，传统EAP已发展数十年，无法兼容可提升系统性能的新兴技术。

为解决这些问题，本研究设计了一种分布式EAP系统新框架：管理平台作为"大脑"控制监控整个系统；消息队列负责数据传输，如同大脑的神经系统；基础平台作为"肢体"执行指令和采集数据。在这种分布式架构下，EAP系统的微小异常不会影响整体运行。与传统系统相比，该架构显著提升了系统的健壮性。同时，分布式架构与消息队列的结合使系统可扩展性大幅增强。实验表明，所设计的分布式EAP系统在稳定性方面表现优异。未来工作将重点扩展系统对更多通讯协议的支持，并为用户提供更便捷的业务逻辑编程方式。

---

往期半导体CIM系统介绍推荐阅读

• 带你轻松了解什么是半导体CIM系统

• 带你轻松了解半导体CIM系统之MES (一)

• 带你轻松了解半导体CIM系统之EAP (一)

• 带你轻松了解半导体CIM系统之MES (二)

• 你轻松了解半导体CIM系统之EAP (二)

• 带你轻松了解半导体CIM系统之AMHS (一)

• 带你轻松了解半导体CIM系统之EAP (三)

• 带你轻松了解半导体CIM系统之APC（一）

参考资料:

- A New Framework of the EAP System in Semiconductor

                       

                        关注一下，后续有更多精彩内容~